I have yesterday submitted the OSMTrack 1.5 update to Apple and they were so fast that just a few hours later the update was online. Wow! I haven't expected this. This is why this announcement comes after the update is in fact available.
A lot has changed in the application since the last update. In fact, I almost have rewritten it with better design, a lot of optimisations, etc., etc. But first things first.
The major visible change is the support of
multiple tracks. Yes, now you can collect as much tracks as you want without bothering to upload them immediately (though you should write the tags and description to not forget where you were). This is extremely useful if you don't have network coverage (or it is expensive - not everyone has unlimited contracts). Or if you don't have time to wait until upload finishes. To support multiple tracks the complete storage of tracks has been re-implemented and now uses SQLite database. It has been done to support future graphical presentation of tracks (and later maps). Even now, it has an advantage that you can store as much tracks as you have place on your iPhone - almost unlimited. Of course, you can also delete tracks by swiping left or right over the track title similar to how deleting of emails has worked in the first version of the Mail application before "Edit" button has appeared (I will also add the Edit button in the next update).
The next visible improvement is the
"Slide to stop" control in place of the stop button. Now I always put my iPhone in my pocket when logging and don't worry about occasional buttons presses.
Now "invisible" changes. I have discovered that the less resources the app uses (mainly the less memory it uses) the better and the faster GPS fix I get. So I have made a lot of internal optimizations in the software. Now with more features it uses almost 200kB less memory than the original version. I have got rid of XIB-based views (pre-compiled user interface stored separately from the application) and rewritten the application to create the UI programmatically. All images used in the application are now when possible scalable and always optimized. Everywhere where only possible I have tried to avoid storing data if I can recreate it fast.
I have not changed the compass implementation though I have seen complaints that it doesn't work well. I tested my implementation and the new Apple-own implementation against a normal magnetic compass. Both implementations are equally bad. Well, not equally but bad. Apple's implementation is much more conservative than mine, the compass needs significant time to start showing any direction. However, I have seen Apple's implementation sometimes showing me consistently wrong direction (in fact, South was where North should be). My implementation is more sensitive, it starts showing some direction almost immediately (sometimes even if you don't move). Of course, in my implementation the direction is not very accurate and my implementation is more prone to errors. But I have seen (almost) correct results equally often in both implementations. I think a much more work has to be done to get significantly better results. I will have to do this work later when I have a graphical map as a background, so I just kept my implementation at the moment since I can easier change it later.
I will post an updated version of the user guide in the next days.
