So Saturday morning I finished the iOS version of my application and published it to the App Store. Of all of the app stores, the approval process with Apple evidently takes the longest. So, whilst waiting for my app to be released, I developed (and published) the Windows Phone version of my app.
There really isn’t much to say about the implementation of the Windows Phone version, other than to mention that the platform again behaves differently to either Android or iOS platforms in even this simple area (sending a TXT message).
I can’t recall where I got the impression that Windows Phone allowed direct sending of SMS messages from code, as I previously suggested. In any event, I was wrong. Windows Phone is more similar to iOS in this area, but contrives again to be different.
On Windows Phone, just as with iOS, you cannot send an SMS message directly. All you can do is pre-populate an SMS message with a recipient (or recipients) and the body of the message to be sent. On iOS you then present a built-in view for the user to modify or complete the message or, in the case of my app, to simply confirm that the message should be sent.
The app is then notified either if the user cancels the message or of the successful sending of the message (or any failure in attempting to send it).
Given that Windows Phone also only allows pre-filling a message, the initial steps in this process on Windows Phone involve very similar code to that for iOS:
var sms := new SmsComposeTask; sms.To := '7275'; sms.Body := Digits.Code; sms.Show;
On Windows Phone, the framework class that provides the SMS UI is SmsComposeTask. I set the recipient and the body of the message and then show the UI.
So far, so much like iOS.
Where Windows Phone then charts its own course is in the fact that once the UI is presented, the user actually finds themselves not in a specialised “Confirm Sending This Message” UI, but simply in what is effect a conversation in the SMS application, albeit with the initial message ready to send.
There is no mechanism for the user to “Cancel” the message in a way that is notified to the calling task.
If the user does send the message then they remain in the SMS conversation with the recipient.
In either event the application that filled in the SMS message has no idea what just happened (or when). The user will either back out of the SMS UI to the TXT-2-PARK UI, or will hit the Windows Home key to return to the phone start tiles.
But, even with these differences, the application is still more convenient to use than having to fumble around with the SMS app from the start, just to send a numeric code to pay for parking.
And at the very least, the process of publishing to the Windows Phone Store was very slick. Within about 45 minutes my app was approved and – I was told – listed, although it then seemed to wake a while for the listing to propagate to the store itself.
So, here’s my latest release app offering:
The Windows Phone Store listing is here.
Size Doesn’t Matter (except when it does)
The Windows Phone app size is reported in the store as “< 1MB" and I can tell you that the actual XAP file is around 60 KB. This is almost 3x the size of the Android version, but where the Android version contains only different sized icons for the app, the Windows Phone version also incorporates images for iconic tiles of different dimensions (small and medium are supported by my app).
In my previous post I mentioned that the iOS version was almost 2 MB in size, making it the heftiest version by a massive margin. In the comments Marc Hoffman of RO expressed surprise at this. Based on his comments I checked my launch image sizes and found that they were accounting for about 1.7 MB of the overall app size (!!!!!).
After removing some gradient effects and opting for a much plainer set of images, the iOS version is now much, much smaller at just 410 KB for the IPA file.
To give some idea of how much space those launch images still account for, the PNG files for the launch images that go into that IPA start out at 470 KB on their own (and that’s after being run through imagOptim, as Marc suggested). So the vast majority of that 410 KB file is still accounted for by those launch images.
So, with the grunt work of getting my app written and published in all three app stores (Android, iOS and Windows Phone) done, in the next few posts I shall discuss some of the aspects of developing for the various platforms using Oxygene that this exercise has exposed me to.
Needless to say, I have learned a great deal about each of the 3 platforms.
Just, that’s not a WP UI (which would have used scrolling numbers to enter data)…