If you’re the type of developer who’s always digging into the Cocoa frameworks to find the stuff that makes your life easier, you’re probably using NSCache. It’s a great class after all. Just store your temporary objects in an NSCache instead of an NSMutableDictionary, and you won’t have to worry about memory usage. Right?
Not exactly. A recent conversation on Twitter reminded me of my own experiences working with NSCache and memory warnings. Although it’s natural to expect NSCache to clear itself in response to a memory warning notification, this isn’t what actually happens. NSCache does automatically evict objects, but this behavior is very unclear and undocumented. In short, don’t depend on it. It’s possible for your app to receive memory warnings, and even crash due to low memory, all without NSCache lifting a finger to help. Instead, keep doing what you’ve always done. Register for low memory notifications and manually release any objects that aren’t essential, whether they’re stored within NSCache or otherwise.
There’s nothing wrong with using NSCache, but until the docs say otherwise don’t count on it to do the work for you.
From The Beast Within:
The experience was overall a good one, with expected frustrations that come with writing code. I still label myself as a “hobbyist” developer, because there’s still tons I don’t know about Corona and app development. But if there’s one thing that can be said about Corona, it’s that it enables almost anyone to write an iOS app; if you can pass an intro-to-Computer Science class, you can write an iOS app with Corona.
As a long-time iOS developer I don’t often think about mobile apps outside of Objective-C. I still believe native frameworks are the correct answer for most apps, but it’s good for everyone that even a non-programmer can bring something to market in his spare time.
Portland Code School is hosting a meet and greet on March 6th for prospective students. This will be their third session, and I really recommend checking it out if you or anyone you know is interested in taking on web development as a career:
Applications are now being accepted for the Portland Code School Summer Session!
Join us for an informal gathering to meet current students and find out more about the program over beer and snacks.
We’ll start the evening with a presentation about the format of the program, what you’ll learn, how we’ll help you find a job at the end, and the application process and requirements.
If you’ve dabbled with Rails but haven’t quite made it to paid developer status yet this may be just the program for you.
Take a look at the event page for full details.
If you follow the Cocoa development community you probably know how big of an issue iCloud syncing is. Watching the WWDC videos from last year you might think iCloud is the next big thing in Cocoa, much like Bindings or Core Data. It’s only when you start really looking at it in depth that you realize just how many bugs and edge cases you have to account for. Trying to enable Core Data iCloud syncing is a huge undertaking for advanced developers, and even the more reliable document and key value store syncing can have its share of problems.
More and more developers have started down the iCloud path and realized too late what the actual issues are. Some have updated their apps to remove iCloud support, and others are not even shipping until Apple fixes some of the problems they’ve run into. I’m definitely part of this crowd with some of my apps I had hoped to ship last year. I started with Core Data before I decided it wasn’t worth the risk and moved my app to document based data storage. Even now I’m not sure I’m on the right track though. My app has a very simple data model, but even after putting in a good amount of work and re-writing things two or three times there’s still work to do.
There are other solutions, including open-source sync frameworks like TICoreDataSync, and Dropbox’s new Sync API. Some of these look quite promising, but in the end it’s impossible for any third party library to achieve the same simplicity and support iCloud promises. I’m hoping Apple realizes just how many developers are affected and is working to improve things. It’s clear that this is hurting the Mac OS and iOS software ecosystem, and if even if some of the problems are resolved it will be hard getting developers to trust iCloud when there are so many horror stories out there.
I’ve had this post cooking for a long time, and I think it’s ready to unveil. If you code Objective-C, this is going to offend you and that’s good. If you aren’t offended, then you don’t care, and that’s bad.
This list isn’t about stylistic things like which line new braces go on (new ones, duh). This list is about potential problems with the code you’re writing on an objective scale. So let’s get started.
Read more on Ash Furrow’s blog. I admit, I’m guilty of a few of these. Hopefully number seven, not using automated testing, will soon be crossed off my list. I’ve experimented with it in the past, but still haven’t adopted it on any of my shipping Cocoa projects.
If you’ve Googled about resizing or cropping UIImage objects, chances are you’ve read Trevor Harmon’s blog post on the subject. Trevor’s solution is great, but unfortunately a little dated since changes to the iOS SDK have introduced a few bugs and compiler warnings if you try to use the original code written in 2009.
I’ve been maintaining my own copy for the past year or so, and I’ve finally gotten around to open sourcing it on GitHub. This fork includes a few of my own changes and bug fixes described in the comments of the original post. If you need to resize or crop an image check it out!
I’m happy to announce that WeatherMin is now available for $0.99 through the ZeroNinetyNine.com bundle, along with eleven other great Mac apps. This is a special one-day sale, including these awesome Mac apps:
- Yummy FTP
- Protect Files
- Compress Files
- All-in Yoga
Check it out here!
I’ve been negligent in posting new articles this year, but despite appearances this blog isn’t quite dead yet. I’ll begin regular postings again soon, but in the meantime here’s a link to an article I guest authored over at iCodeBlog:
One option is to replace the standard camera controls with a custom interface, but that’s a whole lot of work if you just want to prevent the user from taking a photo with the front camera. Fortunately there’s another option: put a transparent button over the “switch camera” button, which will intercept touch events and show an alert dialog. It sounds simple, but as you’ll see there are a few tricks to actually getting this to work.
Check out the rest here!
I’m happy to announce the availability of WeatherMin on the Mac App Store! Like most Mac developers who are bringing software to the App Store, this is somewhat of an experiment for me. The Mac App Store is still in its early stages, and although my hopes are high I have no way of telling what the payoff will be or what unexpected issues might come up. For all the downsides though, I want to do my best to reach all my potential customers. It’s clear the App Store is the best way to do this.
For the time being I will continue to distribute WeatherMin through my own FastSpring online store, as well as release free updates with Sparkle. This is certainly more work on my end, but I think it’s the only fair way to treat existing customers who have already purchased a license.
Oh, and as part of the App Store experiment, I’m also lowering the price of WeatherMin. You can get it now for $4.99, either on the Mac App Store or my own online store. Enjoy!
If you’re interested at all in bicycling, take a look at my latest side project this summer. That Blue Bike is a new blog focused on bike commuting and touring. Expect to find product reviews, technical information, and trip reports from some of the bicycling adventures I’ve been on lately.