Category: tips

Posted on

Important: iOS6 and Data Storage

iOS 6 was released today. It has some important differences in how data is stored. For some users, it will appear that all data is lost. Read this to understand why and learn a workaround.

The information in this blog post, while intended for App Studio users, applies to all web apps, regardless of what tool was used to produce them.

  1. Home Screen data is saved in a separate place from Web App data.

    Prior to iOS 6, SQLite data and localStorage for Web Apps and Home Screen apps shared the same data. In iOS 6, they are separate. If you save some data in the web app, it will not appear in the Home Screen version of the app.

  2. Save to Home Screen does not preserve the user’s data.

    If you do a Save to Home screen from a web app, the data you have entered into the Web App to date will not be copied to the Home Screen app: it will start with empty files. Any data the user has already entered is only available if he continues to run as a Web App.

  3. Data in Home Screen apps is lost when upgrading to iOS 6.

    This is probably the worst news. If you had a Home Screen app in iOS 5 and entered a lot of data into it, you will lose it when upgrading to iOS 6. You can get at it only if you run your app as a Web App.

    If you have end users using apps created with App Studio, you will want to warn them of this.

  4. Data in Home Screen apps are now stored like native apps.

    Native apps each have their own sandbox where their data is stored, backed up and restored to. Prior to iOS 6, Home Screen apps shared data with the same app running in the browser. If the user cleared the cache in the browser, the Home Screen version of the app would lose its data too.

    With iOS 6, Home Screen apps’ data gets saved to a sandbox just like native apps. Backups and restores handle the data properly, and clear cache in the browser will not affect them.

  5. The intermittent data loss of iOS 5.1.1 seems to be cured.

The conclusion? iOS 6 offers much improved saving of data. Home Screen apps are now equal to native apps in this regard. However, there will be confusion over data entered in the browser when an app is turned into a Home Screen app. There will also be difficulties for apps on devices upgraded to iOS 6.

The best solution to this would be for Apple to fix Save to Home Screen to have it copy the localData and SQLite databases from the Web App.

What about Android?

Android (at least to 4.1) works similarly to iOS 5. The data in Web Apps is shared with the browser and is vulnerable to being deleted by a clear cache.

Thanks to Al Richey for helping with the tests to establish this!

Posted on

Exiting an App

A support question we get here regularly is “How do you quit the app?”

You don’t. Notice that other mobile apps do not have exit buttons. When the user is done, he simply starts another app or the menu. Just like on websites: you don’t exit a website, you just go on to the next one.

Apple’s take on this is if an app quits on its own, it will present as a crash. It will therefore not be accepted into the App Store.

Posted on

Dealing with different screen sizes (Draft)

This is a draft of a post that will be of interest to many. We would appreciate any comments from the community on how to improve it – feel free to send comments directly to us or to discuss on the web board.

In the beginning, when the only device was an iPhone with a 320×480 screen, laying out apps was easy. Today, that’s no longer true. App Studio supports 16 form sizes from 240×320 to 720×1280, along with custom sizes.

How can you design an app that looks good and runs well on all these devices?
Continue reading “Dealing with different screen sizes (Draft)”

Posted on

Taking advantage of iOS Retina Displays

The iPhone 4s and new iPad feature ‘Retina’ displays. These displays have twice the number of pixels in height and width as previous devices, allowing images and text to display in resolution so high the human retina cannot make out the pixels. This gives a sharper look to text and pictures. App Studio 2.5.1 adds support for this.

It does not transform a 320×480 screen into one that you can use at 480×960. The extra pixels are all used behind the scene: the screen will look like the exact same 320×480 size to your app. Fonts are drawn using the extra pixels, and images rendered at high resolution if you supply high res versions of your images.

Here’s how to use it in App Studio:
Continue reading “Taking advantage of iOS Retina Displays”

Posted on

How to access SAP from App Studio

The whole idea of App Studio is to make complex things for mobile devices easy. When someone asked us if App Studio could interface with SAP, we knew it would be interesting.

SAP is one of the top business automation vendors. With more than 180,000 companies using their software (and 55,000 employees of their own), they’re a giant. They have created some of the most advanced and comprehensive software for corporations.

So far, however, it’s been difficult to integrate mobile applications with their software. Hopefully, after this blog post, the world will be a bit easier.

Here’s how we did it:
Continue reading “How to access SAP from App Studio”

Posted on

jqWidgets: A collection of powerful new controls

Recently, one of our users turned on onto the jqWidgets Controls. They’re a set of powerful, good looking controls – and they work well with App Studio. The controls are free for non commercial use, $99 otherwise.

In Release 2.5, we added support for some of these controls:

  • Button
  • Chart
  • DragDrop
  • SwitchButton
  • Tabs

We have included samples for these. Before you try them, however, you need to download the jqWidgets library. Download it from http://www.jqwidgets.com/download/, unzip it and copy its ‘jqwidgets’ folder into your project folder.

There are many additional controls we have not made definition files for yet. See one you like? Let us know!

Here’s how the new controls look…
Continue reading “jqWidgets: A collection of powerful new controls”

Posted on

The new name of the manifest file

When you deploy your project, App Studio sends an extra file to the server called the manifest. It contains a list of files which are part of your project and should be downloaded to the device, so it can run offline.

When we released App Studio in 2010, the ending for this file was .manifest. Someone noticed that Microsoft was already using .manifest for another purpose. A few months ago, the standard was changed to .appcache (though .manifest is also fine.)

In App Studio 2.5, the default for new projects is .appcache. Existing projects will continue to use .manifest and work fine. You can control the ending of the manifest file in the new ‘manifestfile’ Project Property.

If you want to use .appcache in your project, you will need to a few things:

  1. Change manifestfile in Project Properties
  2. Delete your project completely from your server and do a full deploy.
  3. Make sure your server gives a MIME type of text/cache-manifest for .appcache files. More info is here.

One of the benefits of using .appcache is that some servers are already configured with the right MIME type. An interesting one is DropBox: if you deploy your project to the Public folder of your DropBox, people can run it from there.

Posted on

Including Databases with your App

While SQLite databases work very nicely on mobile devices, there is no easy way to get them there. You can’t just add the name of your database to the manifest and be able to use it when your app is deployed.

Until App Studio 2.5, that is. When you add the name of an SQlite database to the manifest field in Project Properties, App Studio will automatically convert the database to a format which can be transferred, then convert it back into a database on the device.

Let’s see how this is done. We’ll use the famous Northwind database which comes with many Microsoft products. I went online and found it in SQLite format.
Continue reading “Including Databases with your App”

Posted on

The new NSB.ShowProgress dialog

App Studio 2.5 brings a new dialog box: NSB.ShowProgress. Here’s how it looks:

It floats above your current screen. You can put any message into it that fits. It can be dismissed by your app or by the user.

Here is how to put up a message:

NSB.ShowProgress("Please wait...")

and how to dismiss the message:

NSB.ShowProgress(false)

You could also issue multiple NSB.ShowMessage calls, each time updating the text in the box. This is useful for length operations. You can keep your user advised as to what is going on: the perceived waiting time will be reduced.