Recently Oliver’s blog post ‘Shuffling an NSArray‘ came across my twitter feed. I’m not sure I followed the link with the intention of being critical, but after reading, I felt the need to make a couple of points. Namely, a fairly staunch opinion that in it’s current form, Oliver’s -(NSArray *)shuffled method is an example of poor naming choice. I realize that the original post was intended to showcase the ability to extend existing classes with categories (a powerful and worthwhile concept to understand). However, take into consideration that many developers new to a language will copy and paste code snippets without fully understanding them, and the importance of using proper convention in code examples becomes very clear.
Today, on the train to the big city, I watched the seventh Standford iPhone Programming lecture and got an answer to a question I’ve been having for a long time.
Can I make the back button shorter in a UINavigationView? I like long titles, but it looks ugly on the back button!
The back button of a view that you pushed on the the navigation stack defaults to the previous view controller’s title. You want to make the title explanatory so a long one is good. But if you push another view controller onto the navigation stack you want the space to have an explanatory title on this one, or you need the space for something else.
With so many people using MyAppSales regularly I figured I’d spend a couple of hours working off tickets on the bug tracker. The most important one was causing an app crash if you had sales in one of the newly opened up app store countries.
- Fixed link for country icon retrieval
- Added 3 letter country names below country flags in report view
- Fixed incorrect target name and replaced all code signing identities with the auto-matching ones
- Implemented lazy loading of the 4 main view controllers to speed up startup
- Now all country codes are loaded from the database but only icons are loaded if the country occurs in a report
The new version 1.0.1 can be downloaded from the customer-only Subversion Repository. Source Code licenses are still available here if you’d like to join all those happy customers.
Apple’s double standard was shown to me once more, spoiling an otherwise beautiful Sunday. CXI Gaming was able to sneak iSales Tracker past Apples SDK Agreement and got approved within 2 weeks. How unfair is that?! I mailed Apple the link and and also resubmitted 1.0.1 just to nudge them once again. I also mailed CSI Gaming congratulating them on their luck and advising them to enjoy it while it lasts. The author of Sales Report told me that his first big update got rejected. Most likely the same will happen with iSales Tracker. So customers who first shell out 15 Euros might never get any updates.
As opposed to MyAppSales, where I will continue to provide free source-level support for customers…
3 Months ago, when I started developing MyAppSales I felt confused by multiple XIB files, so I decided to put all view controllers into the MainWindow.xib. Not only does this not really gain you more overview, but this practise slows down application launch. On the iPhone you should defer work whenever possible.
That’s why I revisited my XIB files for version 1.0.1 and moved parts to external files wherever possible. Here are all the steps.
How to send a message from a view controller to app delegate?
That’s a question that everybody asks who is trying to follow the model-view-controller paradigm. There is an easy way to access your app delegate from anywhere in your app.
Every developer with apps in the store has this problem: You have to download your daily reports within 7 days or you loose the information. Several methods have been developed to deal with this, some on individual computers (AppViz), some on web sites (appfigures.com) and some mobile (My App Sales). But all of those have the same problem: to get to the report data they have to scrape the iTunes Connect website.
A practise that Apple tolerates, but does not like. Where Apple has a say, they reject apps for the app store that do that, citing 3.3.7 of the SDK Agreement. And they add “There is no public API allowing information from iTunes Connect to be used in the manner demonstrated by your application.”
And that’s what this petition is for. I don’t want to establish a website for it just yet, but first I am trying to get people aware that we all should post a bug report at http://bugreport.apple.com/ and post your “vote” there by requesting “iTunes Sales Report Download API” from them. Apple collects these reports and when a certain number of people request the same functionality then Apple will be compelled to fulfill their user’s wish.
So the petition works liks this
- put in a bug report and suggest an official API
- comment on this thread
Tonight I fore-went (is this a legal word?) my Cocoa coding time to write this very article about a topic that has begun to burn in my heart and I just have to get it out into cyberspace to get a diskussion going.
You and me and lots of other iPhone developers have strenghts and weeknesses. Some of us can code really well, others are great at design and there are also some people who excel at marketing iPhone apps. There are some commonalities amongst us as well, besides of 99% having a physical iPhone and 66% using twitter to build their network. We all have Internet, as benign as this may sound. We all have websites that have some information on the apps we have in the app store. We are advertising ourselves to the world. Hoping to get noticed. Looking for help. Or simply looking to make as much money as possible with the jewels they have polished in endless hours.
Static, non-machine-readable HTML. Sometimes even worse: Flash! Looking great, but achieving nothing except a good feeling for the person who created it. But that’s just Web 1.0.
A few of us took the next evolutionary step and started to write in forums (the official one as well as the largest non-official one) and get business-centric profiles on facebook or Xing. That’s Web 2.0.
But still those are information silos, you don’t own your posts, you don’t own your content on “social networks”. I say “That’s passé!” Here I am proposing Web 3.0 and all participating iPhone developers will benefit.
For a project I am working on I needed to shuffle the contents of an NSArray without harming the items themselves. NSArray is a convenient container because it does not care about what you put inside. This is because you don’t (put objects into arrays), you only pretend.
You cannot add an object itself into an array but instead you always insert pointers to class instances. NSArray and its bigger cousin NSMutableArray will keep track of the pointers and memory management of the items so you don’t have to. This is a custom category for NSArray that is useful for shuffling the contents, regardless of their class type.
This request of MKureth is so totally crazy that I just had to share it with you:
As impressive as your resumé sounds you lack a couple of essential skills.
Can anyone tell me the best way to create and store data on the iPhone so that the app can read the data but also write to it?
Having tried out all the possibilities that the iPhone platform holds in stock, here’s my opinion.