jump to navigation

A Unified Experience 7 October 2013

Posted by Oliver Mason in Apple.
Tags: , , ,
1 comment so far

Today my friend Zettt posted the following on Twitter: So many people don’t know the difference between their Mac and iOS device. “Do I have to buy app X again for iOS?”. I flippantly replied about my projection for Apple’s next step, which I thought I’d write up in a bit more detail:

Apple is all about the user experience. Things just work out of the box, and the user doesn’t have to think much. You buy an app, and via the cloud you can download updates and copies to your other iOS devices. But there is one jarring line: the distinction between iOS and Mac OS X. If I have an Apple computer and a tablet, why are they so different? There are a number of apps that co-exist on both systems, but I still have to buy them separately, and also link them separately. While my iPhone and my iPad are almost the same in user experience, my MacBook Air stands out like a sore thumb.

My projection is that the two platforms will converge sooner or later. Why confuse the everyday user with having two separate systems? Two distinct App Stores? Either there will be a way to run iOS apps on Mac OS X (a bit like the simulator, only for real), or, more likely, iOS and OS X will merge at some point.

A fully universal app will then not only run on both iPad and iPhone, but also on any OS X device. You buy it once, and it runs on all your machines within the Apple ecosystem. That almost sounds like the original Java promise, where ‘everywhere’ means ‘any Apple device’.

But before it comes to that, my guess is that developers will be encouraged to have OS X versions of their iOS apps. And presumably not charge for them separately. Because, Apple is about hardware, and software is just a cheap commodity. If you want to be featured (and rake in the cash in the AppStore) you better make sure you have an OS X version as well. You know it makes sense: users can then buy any Apple hardware and run your software. Don’t worry about switching from the iPad to a MacBook, you can take your software with you.

This is of course pure speculation. But I somewhat think it would make sense to combine iOS and OS X in the long run. With the introduction of different screen sizes and AutoLayout developers are already weaned off hardcoding screen dimensions. And Apple has got a ton of experience in transitioning CPUs, as evidenced by the switch to Intel a while back. So why not switch from Intel to A7? Or just have iOS apps running on an A7 interpreter. It would open up a new range of Apple computers to casual users whose barrier to entry is dramatically lowered: they have all the software they need already, and no longer need to think what OS they’re running.


More than eye candy 19 February 2013

Posted by Oliver Mason in Apple, iphone, objective-c.
add a comment

For an undergraduate module in Digital Humanities I am currently coding an iOS app designed by our students (see @iBrumApp for the related twitter feed). This is a tourist attraction app about Birmingham. The students collect data on a number of interesting locations (images, descriptions, coordinates, …) and encode them in XML ready to put into the app.

In the app so far there is a map screen, which shows the locations of the attractions. This can be swapped for a list view, which shows the attractions as a table in text form, possibly with a short description and a category label. A segmented control allows switching between the two views.

Under the hood there are two views on top of each other, with one of them hidden. Pressing the segmented control unhides the hidden one and hides the previously visible one; that works fine. There is a simple method in the view controller which swaps the two views:

                 out:(UIView*)toHide {

    [toHide setHidden:YES];
    [toShow setHidden:NO];

However, it feels a bit sudden and ‘in your face’, the way the views are changing.

So, it might be better to soften the transition somewhat, for example with a cross-fade animation. Basically the visible view would become increasingly transparent, while the hidden view becomes increasingly opaque, until the old one is completely invisible. This is very easy to do with CoreAnimation:

                 out:(UIView*)toHide {

    [toHide setAlpha:1.0];
    [toShow setAlpha:0.0];

    [UIView beginAnimations:nil context:NULL];
    [UIView setAnimationDuration:0.75];
    [UIView setAnimationCurve:
    [toHide setAlpha:0.0];
    [toShow setAlpha:1.0];
    [UIView commitAnimations];

[Note: there is probably a more elegant way using the new block syntax of Objective-C, but this works just fine].

This fading animation has indeed the desired effect, making the transition much smoother and less sudden; I feel this is an improvement in the feel of the app. It’s only a small thing, but if there is one thing you pick up as a developer in the Apple ‘eco-system’ it’s that small things matter. Attention to detail is important.

One thing I have not yet explored (as I’m only testing it with a small sample data set of two locations) is the performance: I have the suspicion that having two superimposed views with transparency might slow down the whole thing, as the iPhone tries to render the other view despite it being transparent. But in that case I can just add a line that sets the ‘hidden’ property to disable the view completely should that prove to be an issue.

On Planning and Reality 3 June 2010

Posted by Oliver Mason in Apple, iphone, objective-c, programming.
add a comment

When I got my iPhone a little more than a year ago, and started developing programs for it, I had a clear idea what my first program was going to be. However, as always, things turn out quite different from how you think they are going to be…

First, it did take me a bit to get used to Objective-C. Not because it is very different from Java (I used to program in C after all before Java came along), but because all the classes in the Cocoa framework need to be learned. There are subtle differences between those and their Java cousins, and after a bit more experience I believe that the Cocoa classes are actually more powerful and easier to use than their Java counterparts.

Some teething troubles, lack of automatic memory management on the iPhone, and a surfeit of squa brackets meant further delays. Finally I had a program written, but it needed more work on the graphics side, artwork and so on. The stuff that really makes a difference, but is very time-consuming and hard if you’re not used to using graphics software. So the easier way out was to write a different program, which is lighter on the artwork.

This then was a todo-list program, which is also suitable for planning small projects. I wanted a program like that, but didn’t want to fork out the money for Things, which also looked a bit like overkill. On the life hack blog I read an article by Dustin Wax on his moleskine setup, and that seemed like something usable, which I then went about implementing as an iPhone app. With a bit of help from a friend with the icon design, and thanks to freely available sound files and icons, ePlanner was born.

In ePlanner I tried out Core Data, which is really a lot easier than messing about with SQLite directly. It uses both tabs and navigation views, and a lot of tables. I found it rather tedious in that all the classes were almost identical, but only almost, not 100%, and it’s hard to see how that could be changed. The behaviour of those classes is ever so slightly different.

The submission procedure was very easy, thanks to a description I found on the web. My app did get rejected, due to a crash on a 3GS; but I don’t have a 3GS, so I could only test it on a 3G and an iPod touch. Thanks to Instruments I could track down the error, which was of course a memory management issue, but one without consequences on the machines I could test it on. After that was changed, the app went through, and has indeed been bought by people all over the world.

It is really a nice feeling to think that someone in Argentina is using my app, as is someone in Hong Kong, some people in the US, Sweden, etc. I used some free Google advertising at the beginning, but that is really expensive, though when I stopped it, sales began to trail off. But that could also have been an effect of it slipping out of the ‘newly released’ slots.

It is indeed not too hard coming up with a program that does sell. The overall process is not too hard, though there were some frustrating moments battling with the various code signing and certificate issues that Apple requires.

I since have bought an iPad, and am thinking of porting ePlanner to this; however, I’ll give it a while so that I get used to how the iPad works. Knowing your way round the platform makes it a lot easier to develop good software, and I am not yet sure how the UI design for the small iPhone screen can best be translated to the iPad’s larger display. But it will come, and I will describe the process on this blog…!

In the meantime, I will re-visit some of my previous program ideas, as it is really not hard to turn them into something that will end up in the App Store, and it is really satisfying to do so.

Single user vs Multi user: how will the iPad work? 17 March 2010

Posted by Oliver Mason in Apple, iPad, iphone.
1 comment so far

Note: this post is somewhat speculative, as I obviously do not have an iPad (yet!). It is simply an observation that got me thinking about how it is going to be used, and how that possible usage will influence the user experience.

I suspect that in our house the iPad will be a multi-user gadget.

I have an iPhone, my wife has got an iPod touch, and the kids currently use a clapped-out ancient Sony Vaio laptop whose disk is about to fail. Everybody has their own device to do things on. However, this is likely going to change when we acquire an iPad. I envisage this as being a general device that just lies on the sitting room table, to be picked up by whoever wants to use it for reading their email, checking something on Wikipedia, playing a quick game, adding an entry to a calendar, looking up a phone number, and so on.

When I check mail on my iPhone, it is set up to look at my email accounts. Similarly, the calendar is sync’d with my general calendar, and the address book is too. I don’t (and cannot) easily switch between identities (though it is possible to do so with mail and calendar). Some games that I play on my iPhone store their state in case of interruption, and I can resume them later. The same applies to other applications, which usually have one set of data they work with.

This is OK for a phone. Typically you have a phone, and you’re the only one using it, otherwise it’d lose some of its usefulness if you don’t know who you will reach when calling a particular number. But if the iPad is shared between people, how can I avoid reading my wife’s email, or swamping her address book with all my student email addresses (which Google puts into it automatically)? If I play a game, and then have to stop and go back to it later, what if one of my daughters wants to have a go in-between? She might not only end the game I’m playing, but also mess up my high-score records. My todo-list application only has one set of todos, so what if I look at it and suddenly find “Feed my puffle on Club Penguin” on top of my priorities?

On a Unix system you have different user accounts, and you log in and out; this avoids the problem on Mac OS X. But logging in and out is tricky if a system is shared. If I forget to log out when I interrupt my task, and the device is locked, nobody else can use it until I have come back. And how can this be made easy, without constantly having to remember a user name and password?

I somehow suspect that this will be an issue for which there is no satisfactory solution. But if the iPad is to become a general household item like a television or a radio, then there needs to be some non-intrusive way that allows easy sharing. I’m looking forward to finding out what Apple came up with here…!

What’s a UITextEffectsWindow? And why is it receiving messages? 17 September 2009

Posted by Oliver Mason in Apple, iphone, objective-c, programming.
1 comment so far

I just spent several hours (or at least it felt like several hours!) in frustration, searching a trivial bug. I’ve been testing a quick’n’easy prototype screen with an UIImageView and four UIButtons. The buttons are linked via an action to a view controller. And every time I press a button, my app conks out complaining that -[UITextEffectsWindow buttonPressed:] was an unrecognised selector. I checked the memory address, and it said it was my view controller, just before that exception was thrown.

I was ready to put the blame on some mistakes with Interface Builder, until I came across the solution (indirectly) in a blog: here the problem described related to properties, and the difference between vc = … and self.vc = …. I had another look at my code and quickly found the offending line: I had the view controller as a local variable in the app delegate’s ‘viewDidLoad’ method, and I autoreleased it. In other words, by the time the button was pressed the view controller no longer existed, and hence I got that weird error message.

This was not helped by the fact that ‘UITextEffectsWindow’ is not mentioned in the documentation anywhere, as it seems to be an internal UIKit class, but at least it appears to be consistent.

So, if your button presses send messages to ‘UITextEffectsWindow’, make sure to check that your view controller is still alive!

Application Promiscuity 7 September 2009

Posted by Oliver Mason in Apple, iphone, objective-c.
1 comment so far

I was getting a bit bored with the slow progress on my Esperanto dictionary app, and over the holidays I started work on a few other ideas I had. One was a Maths-drill program for kids, as the ones that are already out there (at least the ones I tried) don’t seem to be ideal (nothing ever is ideal, though!). So I tried writing another app so our kids could play and practice their maths skills.

That app is almost done, just the artwork and sound effects are missing. At the moment it looks pretty rubbish (but looks aren’t that important as long as it works and doesn’t crash!), and the sound effects are nicked from somewhere, so I have to replace them with free ones. Again, the purpose was to try things out.

That app was quite fun, and also easy to do. More on that later…

The next app is one that supports teaching and learning students’ names. This makes use of a navigation controller, which is slow going. I’m picking up loads of experience in Objective-C quirks along the way. For example: avoid using NSNumbers as the keys in a dictionary if you want to save it using writeToFile later on…

Overall it’s very exciting, and the iPhone is a fun platform. It’s really great to see your own stuff amongst all those polished apps, and provides great motivation to do better.

NSData Naughtiness 13 July 2009

Posted by Oliver Mason in Apple, objective-c, programming.
add a comment

Well, this is not exactly NSData’s fault, but I ran into a problem (for the second time; the first time I bypassed it with a short-cut) when reading text data from a file.

Occasionally there was random garbage at the end of a line, which I could not understand. Incidentally, I was reading a number of full files in one go each into an NSData instance, and converted that into an NSString with the correct encoding; this I would then tokenise and add to another file. So the garbage was actually at the end of each file. I then found that I can directly initialise an NSString with the contents of a file, and the problem disappeared.

Now I want to produce concordance lines, and I jump into the middle of the file to read a stretch. First I run into trouble with the encoding: as the data is UTF8-encoded, a random jump can end up in the middle of a multi-byte character. NSString does not like that… but here I can just test for that and skip the initial bytes. The same problem obviously also happens at the end, where the final multi-byte character could be incomplete. Again, truncation seems the easy way out.

But I also then had the issue with the occasional random garbage again! NSData seems to be at fault, and this time I can’t bypass it, as NSString can only read a full file. Quick websearch, and the solution crops up (in an aside) on stackoverflow.com: the data that NSData returns from the -bytes method is not zero-terminated, but NSString’s -stringWithUTF8String expects that, hence the random garbage of the unterminated data. In a way I’m surprised that it actually worked most of the time!

Dictionary Dangers 9 July 2009

Posted by Oliver Mason in Apple, objective-c, programming.
add a comment

I just spotted a bug that cost me several hours yesterday, without having a clue what was going on. I’m currently working on a program which indexes texts, and as I encounter words, I add them to a NSMutableDictionary with their positions in the text. All was working well, until I tested it on a bunch of texts, and it failed with some obscure message about key-value coding. I then added some NSLog messages, and discovered that the token it failed on was the at sign, @.

Today I had another look at the documentation of NSMutableDictionary, and especially the method valueForKey: where the problem seemed to occur. And there it was: “If key does not start with “@”, invokes objectForKey:. If key does start with “@”, strips the “@” and invokes [super valueForKey:] with the rest of the key.” Suddenly it dawned on me: I was using the wrong method. Instead of valueForKey: I should have used objectForKey: – the plain @-sign is discarded, and leaves an empty key (which did of course make the error message less comprehensible, as I couldn’t really tell it was empty).

Quick change in the code, and it works. Problem solved!

Lesson learned: always pay close attention to the available methods, and make sure it is the one you want, even if the one you’re using sounds like it’s the right one. And read the docs carefully!

Making Progress! 26 June 2009

Posted by Oliver Mason in Apple, iphone, objective-c, programming.
1 comment so far

DAY 11 and the pace is picking up. I managed to sort out two of the four tabs of the app, one including a table display of Esperanto/English dictionary entries (with the proper Esperanto diacritics), and the other one being a live-search on the English gloss entries. This one even pops up an automatic keyboard when first selected; the tab bar controller sends it a message when it has been activated. I even managed to answer a question on stackoverflow.com on that issue.

I also found somewhere a hint on how to automatically shrink the label size if the text is too long, wrote a converter from the Esperanto x-notation to unicode, etc. Really pleased! Both of these will appear here later.

One thing I don’t like too much is writing all the UITableViewDelegate methods when using a table. Quite a lot of boiler-plate code, but then, it is quite powerful. I just couldn’t be bothered writing yet another set of those methods for the final tab, the info view part. But there is nothing technically difficult with it. Objective-C is also getting easier and easier, and the auto-completion feature and API doc integration of XCode really helps. Though I think for serious code I will still use vile…

That leaves pretty much only the core part of the app: the Esperanto morphological analyser. I will implement this as a finite state machine, and working with Cocoa has given me the idea to implement it using delegates; an abstract hull which calls methods on the delegates whenever it needs to retrieve data, or match something. I have the feeling that this is pretty similar to Erlang’s OTP frameworks.

It is a really rewarding experience to see your own app on the iPhone. If only I was better at designing the tab bar icons! And I can already foresee one objection: one of the tabs has a star icon, the star being the Esperanto symbol. I think I need to change that, as the star is reserved for the ‘favourites’ meaning, and I don’t think Apple would appreciate the use of a star (even if it looks slightly slimmer) with another meaning.

More problems solved 24 June 2009

Posted by Oliver Mason in Apple, iphone.
1 comment so far

DAY 10, second part. I was really annoyed by those database errors, and built in assertions to check for the size of the file, and whether the file existed at all. I think sqlite creates a database if the file doesn’t exist, and on subsequent runs the database is then empty and failure happens.

Then I had the nice situation where the program worked in the simulator, but not on the device (I wanted to check the speed on the actual phone). Again, first the file doesn’t exist, and then it’s empty. XCode didn’t seem to copy the file over. Finally it dawned on me, as I was searching for mentions of problems with copying files into the documents folder: my database file was not in the documents folder, it was within the application bundle. I thought about copying it over when the app first starts, but then, why bother? It’s a read-only database, so all I needed to do was to change the path in the db init code, using the application bundle instead of the documents folder, and hey presto, success!

I guess the problem was that I looked at the sample code for db stuff in the iPhone development book. Here a database is created in the documents folder, and I assumed that would be where my db should reside. Confusing, but finally sorted. Now I can go to sleep in peace!