Category: iOS

Ever wanted to debug your app while it’s actually running on an iPhone or iPad? You can do so if you have a Mac.
Continue reading “Debugging your app on an iOS device”

Recently, Thomas Gruber raised the question about when databases get overwritten on an iOS 6 device. We looked into and found it was indeed a good question. First, there were some bugs in the SQLImport() function that needed to be fixed. Second, we found that a couple more options were needed to make it really useful. Make sure you are running at least version 2.6.0.2 of App Studio to get these features.

We made changes to the 4th parameter of SQLImport():

   SQLImport(Json, DB, callback, overwrite)

The fourth parameter, overwrite, now has 4 possible values. It can be used in the function and in the manifest.

NSB.overwriteAlways	overwrite the existing database (default).
NSB.overwriteNever	only write out database if it does not exist yet.
NSB.overwriteIfVersionDifferent	overwrite if the version number of the database has changed.
NSB.overwriteIfVersionSame	overwrite if the version number of the database is the same.

The old True/False options for the overwrite parameter will continue to work as before.

Also, SQLImport now returns a string with the status of the callback function.

Here are some use cases. (You’re welcome to rerun the tests on other devices or versions of the OS – let me know if you get different results!)
Continue reading “When do databases get overwritten?”

iOS 6 brings a nice new feature to both iPads and iPhones: the ability to run your app in kiosk mode. Your app becomes the only one running on the device and the home button is disabled. Turn the device off, turn it on again – your app is still running. This is ideal for single purpose apps: order taking, inventory, surveys; where the device is used for one thing only.

Here’s how to enable it:
Continue reading “Running your app in Kiosk mode”

UPDATE: This is no longer a problem in AppStudio 3. See AppStudio 3: Moving, resizing and hiding controls.

In App Studio 2.5.0, we introduced some functions which made it easier to resize controls. They worked nicely on all versions of iOS and Android, both on the desktop and on device. This is broken in iOS 6.

Here’s the workaround:

Button1.width = 100            'works up to iOS 6

Button1.style.width = "100px"  'works for all versions of iOS

This affects the following App Studio properties: .width, .height, .top, .left, .Visible and the .resize function.

Beneath the covers, we use JavaScript’s __defineGetter__ and __defineSetter__ functions. While they still exist in iOS6 JavaScript, they no longer change the values in html elements. Here’s a simplified version of what we’re doing in JavaScript:

Button1.__defineSetter__('width', function(x){
	Button1.style.width=x
	});

Before, this code would change the value of Button1.style.width. It does not anymore.

We have reported this to Apple.

It seems iOS6 has introduced a ‘bug’ in Ajax calls – specifically it caches any Ajax “POST” call so that subsequent reads access the cached file instead of the original on your website which you may have changed.  The solution is to change the Ajax call just slightly so it is unique.

Here is a workaround that forces the Ajax call to access the original. The original code:

  res=Ajax(filename,"POST")

The corrected code:

  res=Ajax(filename,"POST","/no-cache?" & Date)

Thanks to Helen Sandoz for this tip!

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!

If you save an app to the home screen on an iOS device, you can display a nice splash screen when it launches. But what if the user switches to a different app, then returns to yours? It will have quit and needs to launch again.

You can save the current state to localStorage and write some code to go right back to where you were: but the splash screen will show again. You can suppress it by adding these lines to your restart code:

Dim headerChildren=document.getElementsByTagName("head")[0].children
Dim i=0
Do While i<UBound(headerChildren) And headerChildren[i].rel<>"apple-touch-startup-image"
  i=i+1
Loop
document.getElementsByTagName("head")[0].removeChild(headerChildren[i])

This code finds the splash screen in the header of the page and removes it.

An amazing new product crossed my desk today. iWebInspector lets you open up a debugging session on an NS Basic/App Studio app that is running in the iOS iPhone or iPad Simulator.

It was developed by Max Firtman (who has come up with other innovations that we at NS Basic have used), based on a discovery by Nathan de Vries on how to enable the Remote Web Inspector on iOS 5.

Since the iOS Simulator only runs on Mac OS, this tool requires a Mac. You’ll also need to download Apple’s XCode, which includes the iOS 5 SDK and the Simulator. It’s a 1.6 gig download, but easy to install once it is there. You won’t have to learn XCode or even how to start the Simulator: iWebInspector will take care of that for you.

Here’s how iWebInspector looks when you start it: (this is Beta 0.9 – expect it to get better looking quickly):

If you click on Open iOS Simulator, the Simulator will start automatically. If it is purely a web app, open it in Safari then choose “Load from Safari”. If it has been saved to the Home Screen, start it and choose “Load from webapp”. PhoneGap apps can even be debugged: enter the App name and “Load”.

This tool will be especially useful for debugging apps which can only be tested on a device.