Sep 4
An iPad app I have been working on recently began being jettisoned by
the OS for using too much memory. The annoying this was that there was
no sign of leaks, and while running the app through the Allocations
Instrument, there was no sign of excessive memory usage.
The app requires the main screen to have a large background image that
changed as a UI control is modified by the user.
I checked the usual suspects – leaks, allocations and the stack traces
therein. What I found was that there were several large blocks of
memory being malloc'ed from within CoreGraphics, and that this memory
appeared to have been allocated outside of the scope of the code I’d
written:
After a lot of tracing this problem, I found the culprit:
[UIImage imageNamed:@'Someimage']
Calls to this method cause the named image to be loaded into memory
and cached. The image will remain in memory for the duration of
your apps lifetime, and, if you have enough large images and calls to
this function, they will cause the OS to jettison your program.
The Solution
Don’t use [UIImage imageNamed:@‘Someimage’] unless the image is small
and you want to use it repeatedly in your app. Instead, the following
snippet will allow you to load the image, then release it’s memory
once you’re finished:
[UIImage imageWithContentsOfFile:path];
Note that imageNamed is not evil, it just needs some extra thought
when using it. If there are enough images of a significant size, then
the memory retained by this call may get your program forceably
removed by the OS.
Sep 4
If you have a number of validations on a model, then you can quickly end up with something like this appearing in your error blocks:
I'd prefer to see only one error message for each attribute:
This can be achieved by creating an errors_helper.rb file in your apps helpers folder, and pasting the following code (mercilessly modified from
this post by Bert over on RailsForum):
Jul 28
If you’ve spent time with Rails, you’ll already know that Formtastic is ace, and constructing forms using the SemanticFormBuilder keeps your code neat, and the output sensible and semantic.
More often, I find the need to include a control in my forms that allows the user to find and select a single LatLng, and, up until now, I’ve been adding in hidden fields and creating js that allows me to present a map control.
In an effort to reduce this duplication, I’ve built a Rails plugin for Formtastic that provides a new map_input and multi_input function, which means if you have a lat/lng pair, and you want to let the user fill out these values, all you need do is:
<% semantic_form_for @venue do |f| %>
<%= f.multi_input :latitude, :longitude, :as => :map %>
<% end %>
Note you’ll also need to include the Google Maps script in your header:
<script type='text/javascript' src='http://maps.google.com/maps/api/js?sensor=true'></script>
Installation
You’ll need Formtastic
Install Maptastic as a plugin:
script/plugin install http://github.com/MattHall/maptastic
Development
This plugin is under development. It’s pretty simple, and patches are very welcome.
The Repo is available on GitHub: http://github.com/MattHall/maptastic
Report bugs here: https://matt.purifyapp.com/projects/maptastic/issues
Jul 19
When building a new feature into a web app, it’s useful to have beta testers use it for a a while before it’s fully launched in order to catch any last minute bugs, to get an idea of whether the new feature feels right and if it actually solves the original problem.
It is also sometimes desirable to have the beta testing process work from within the existing production app, in order for the production data to be used, and to prevent beta users from being isolated from other users. This may not be the case with an application that does not promote interaction between users, and in such cases, it is probably desirable to create a beta deploy of the application.
The following is the method by which I beta test features in my own (Rails) apps – YMMV.
Give certain users beta status
This is fairly simple – either add a boolean beta field to the user model or, if you’re using something to manage roles, add a beta role to the users you’re adding to your beta program. Be sure to protect this attribute:
If you’re using roles, then you can segment your beta users, granting access to individual features if necessary.
Hiding actions fron non-beta users
In your application_controller.rb define the following function:
def require_beta
@current_user.is_beta?
end
In any controllers that have actions that need to be protected, you can then write:
before_filter :require_beta
Hiding UI elements
There will probably be links, forms and UI elements that you’ll need to only display to beta users, so, in your application helper:
def beta(&block)
yield(block) if current_user.try(:is_beta?)
end
def non_beta(&block)
yield(block) unless current_user.try(:is_beta?)
end
Then, whenever you have a UI element you only want to appear to beta users, just wrap it in the beta call:
<% beta do %>
This text will only be shown to logged in beta testers
<% end %>
<% non_beta do %>
This text will only be shown to normal users and non-logged in users
<% end %>
Jul 16
If you haven't seen Flight404's stuff yet, you're missing out.
