Tag Archives: software engineering

Building an HTML5 Web App

Posted on by

I have an Android App called Concert Tipper but as yet I have not been able to get the same cross platform App approved by Apple for inclusion into the Apple App Store. I am also building an HTML5 Web App version which will run on any HTML5 compliant smartphone. The Web app will be totally under my control and not subject to any review process just to get it to run on your device.

Users don’t really care about any of the problems associated with getting approvals into App Stores. They just want to run the App on their device no matter what smartphone they use. This is the promise that HTML5 holds. We shall see to what extent that promise is delivered.

I’ve been developing software systems of all kinds since 1979. I’ve been building web sites and Internet services from around 1998. I am no stranger to desktop applications, server applications, web applications and embedded systems to name a few. Picking up the basics of HTML5 and Web Apps recently was a challenge but no more so than mastering any new technology. In fact I have to say that I have worked on far more complicated things in the past.

Before I started to convert my Adobe AIR App to HTML5 I looked around at the many Javascript frameworks that are currently available. This was a chore in itself and it took me some time to decide to use the JQuery Mobile framework to provide a user experience similar to what you might find on a mobile App and also similar to the interface that I developed for the AIR app. I also looked at some templating and data management frameworks but decided not to use them as they all looked a little bloated and overkill for my purposes. Instead I opted to code any requirements in Javascript on the client and PHP on the server.

The server side back end database and scripting already existed of course. I had developed this for the AIR apps. This meant that I could concentrate on the HTML5 and user interface which I have to say is coming along nicely as I speak.

Problems? Yes there are some, of course there are. Most of the time consuming ones tend to be caused by incompatibilities between mobile browsers. Some HTML5 compliant browsers are more compliant than others and getting the App to work satisfactorily on all devices is the latest challenge. Safari on the iPhone appears to be one of the better browsers in this respect.

Speed of operation and user responsiveness is also a challenge with a Web App. With the native AIR App I was able to cache a lot of data and provide the user with a fast UI even on the slowest devices. The Web App requires more time downloading data from the server and Javascript tends to be a little slow on older devices. The trick here is to code an acceptable compromise between download/processing time and user responsiveness.

I’m sure that I will come across more challenges before this HTML5 App is completed so I better get back to work.

Waiting For Review In The Apple App Store

Posted on by

I can’t tell you how relieved I felt last week when I finally managed to get the App uploaded to the Apple App Store and saw the status change from “Waiting for upload” to “Waiting for review” instead of “Invalid binary”. The process had been painful and there was precious little help from Apple in diagnosing the problems.

Provisioning for distribution

The first step in the App Store submission process is to prepare the binary package in a format acceptable to Apple. This involves obtaining two new files from the development portal. You need a distribution signing certificate and a distribution mobile provisioning file. These files are used to create the distribution binary package in the same way as the development packages are created for testing the App on suitably provisioned test devices.

This is a fairly straightforward task but I have a big problem with it because it means that I had to create an upload package using files and tools in a way that I can not test before uploading to the Apple Store. This might not sound much of a big deal but I’ve been creating software solutions for more than 35 years and experience tells me that that if something has not been tested then there is likely to be a problem with it. This time I had to trust myself to get it right and hope for the best.

You can not do this without an Apple Mac

The next problem was uploading the package to the App Store but before I could do that I had to take the “.api” file, un archive it and re-zip it up on an Apple Mac computer. The archive can only be produced on a Mac as it adds some codes that are not used by other archivers. As I had created this App as an Adobe Air project on a Windows machine I had to find a Mac to perform this step. I also knew that the package can only be uploaded to the App Store from a Mac and I don’t actually own a Mac. I had to find a friend with a Mac who was prepared to do this for me.

Luckily my friend Huw has a Mac and he was interested to see how this process works so we were set to go. After he had unzipped and rezipped the package he downloaded the Application Uploader software and attempted to upload the App for me. When this App finally gets approved I will need to acquire a Mac to maintain Apps in the store.

Restrictions on members

We noticed that we were only allowed to upload Apps using the member account designated “Agent”. It was set to the originator of the main account who was not involved with the development process. We tried to reassign the Agent role to one of the developers using the portal. Unfortunately all attempts to do this failed so we ended up logging in with the main account that we knew had the Agent role assigned. Not ideal but that seemed to work.

Invalid binary!

All appeared to be well during the upload and I saw the status change from “Waiting for upload” to “Upload received” and I thought we were winning. Then the status changed to “Invalid binary” and our hearts sank.

What was wrong? Well the App Store is supposed to send you an email when this happens containing a description of the problem but we didn’t get anything. We tried again from different accounts and attempted other minor changes but nothing worked. Invalid binary every time. It took us two days to find the problem and in the end it was so simple yet so not obvious. I shall leave the explanation of this to a later post.

So now it is uploaded and it has a status of “Waiting for review”. Review is when a human tester will give the App a test drive and I have every reason to believe that they will find something wrong with it that I will have to fix before they approve it. Until then I can relax.

If you have an Android phone you can try it out right now by installing it from Google Play Concert Tipper. If you have an iPhone then it should be available in the Apple App store soon.

Submitting An App To The Apple App Store

Posted on by

Why does it take so much time and effort to get a mobile App submitted to the Apple App Store?

Apple has a submit and review process that rivals getting accepted to do quantum mechanics at university. They force developers to produce good Apps whether they like it or not. If it isn’t good enough then it will get rejected. This might be good news for users but it isn’t so good for developers.

Submitting an Android App is child’s play in comparison

I developed a mobile app and submitted it to the Android Play site about three months ago. It’s an Adobe AIR based app written entirely in ActionScript 3 which makes it a cross platform app that can easily be ported to the Apple iOS system for use on iPhones and iPads. I thought that this would enable me to submit the same app to the Apple App Store very soon after it was established in the Android Market but I was completely unprepared for the additional work I would have to do before I could submit to Apple.

Three months after submitting to the Android Play site I am only now at the point where I feel confident in submitting to the App Store. So why has it taken so long to get the Apple version ready? Well that’s the purpose of this post. Read on to find out where all my time has gone.

First steps in preparing an App for the App Store

The first thing to do was to get a test version of my app running on an iPhone. Packaging the Air app for iOS is fairly straightforward using the Adobe Air sdk tools but I did have a problem trying to use the latest versions. I could not get it to build successfully and I finally reverted to version 1.6 because it works and I didn’t have the time to work out why later versions do not. I shall revisit this problem once the App is in the App Store.

Now you might think that once you have built and packaged your app for iPhone you should be able to transfer it to your iPhone and start testing it. This is indeed exactly what you would do with an Android App but not when it’s an Apple device I am afraid to say.

99 dollars just to run your own App on the iPhone that you own 

Before you can run your App on the iPhone that you paid good money for you have to get yourself an account at the Apple Development Portal which will cost you $99 for a one year subscription. Why do you need this? Well there are a few requirements that your App has to fulfill before it will run un an iPhone and you can only fulfill these requirements through the development Portal.

The first thing you need to get from the developer portal is a Developer certificate. This can only be obtained through the portal and you use it to build your App binary package. The purpose of the certificate is to authenticate your App and without it it will not work when you put it on your device.

The next thing you need from the portal is a provisioning file which is tied to the device that you run it on. Yes this means that you have to build as many binary packages as there are devices you want to test it on. This can be a real problem if you have many testers because every time you make an update you have to build a new binary package for each tester one at a time. The appropriate provisioning file also needs to be loaded onto the test device before the App can be loaded and run.

Yippee it runs on my iPhone! A long way from submitting to the App Store

So you have your developer certificate and a mobile provisioning file for your App. You have loaded your provisioning file onto your test device and built a binary package that you have loaded and installed onto your iPhone or iPad via iTunes. You start the App on the device and it works. Great you want to upload it to the App Store immediately so that everyone can use it. Well no, not yet. You still have a lot to do before you can do that.

When I got to this point I set about testing it to make sure it worked the same as the Android version. It’s an Air App so it should work exactly the same right. Well it should and it mostly does but there are some differences that need to be identified and corrected for all platforms you are targeting. I found that some events do not behave in exactly the same way, especially around start up. There are also some important differences with events from Web View windows so it’s important to check it out thoroughly.

I was testing the App on an iPhone 3gs because it’s the only Apple device that I personally own. This is ok but you really do need to test it on more than one device and with more than one tester. I have a developer friend with an iPhone4 so I asked him to do some testing for me. His name is Huw Nichols

Always get someone else to test your software

Huw found some bugs for me very quickly. It’s funny how you can test your own code until you are blue in the face and still miss bugs. Luckily I am used to this and make a point of writing maintainable code that is easy to fix. This enables me to correct bugs quickly so the only real problem is discovering them in the first place. I’m always happy when someone finds a bug for me because I know that once I’ve fixed it then it’s one less bug in the App.

Conforming to Apple guidlines

Then a more pressing set of issues started to emerge. I had begun to study the Apple developers guidelines and I realized that my App didn’t conform to several of the requirements. While it was perfectly acceptable in the Android world there were some points that I felt might get it rejected by the Apple review team. There is no review process for Android Apps so there is no risk of it being rejected for non conformance to any guidelines.

Now it can take several weeks to get an App reviewed by Apple so I didn’t want it to get rejected if I can help it. It took me a lot more time to mould my App into Apple form than it ever did to fix the bugs we found. If you are developing an App for iOS then I would strongly suggest that you read the guidelines before you start to avoid lengthy delays at the end.

Well I am nearly ready to submit to the App Store. I have collected together most of the things that I will need. Icons, keywords and descriptions are just a few of the things required. I am now writing a set of review notes for the review team. They need enough description to enable them to test everything including any test accounts and other things that they will need.

Don’t leave unfinished features in your App

It was during writing the review notes that I discovered another issue that could get the App rejected. I had built in a messaging system which I had planned to activate from the server post launch. I realized that Apple might see this as an unfinished feature which is something that they will reject Apps for. After much soul searching I decided to implement the bare minimum which was to send the App a welcome message on installation. This took a couple of days to put in but I think it was worth it.

I’m hoping to submit the App to the App Store very soon so watch out for my next update.