Smartface Get Everything Done About Memory Management for You

We’ve done everything what you expect from Smartface. Analyze common problems for memory management on mobile devices and packaged you all in one solutions. You don’t need to take care of platform based memory optimizations while developing with Smartface App Studio.


Memory management is the hardest part of mobile development. Mobile devices, from cheaper ones to the most expensive ones, have limited amount of dynamic memory compared to our personal computers. While you’re developing your application; you need to take this constraint into consideration by freeing the resources you don’t need and minimize them not to destroy user experience. If you fail to manage your application’s memory resources which are provided by the operating system, that means you are going to face with random crashes, UI freezes and finally a bunch of angry users. Also your application’s poor handling will affect other idle background applications; they will get closed by system to provide you with more memory (usually the memory you don’t even need).

Poor memory management shows itself in various ways:

1-    Allocating more memory space than application actually needs,

2-    Not releasing the memory area retained by application,

3-    Releasing a memory area more than once (usually as a result of multi-thread operations),

4-    While using automatic memory solutions (ARC or GC), losing the tracks of your objects.


Before iOS version 4.0, developers had to manage all the objects which were created themselves. Or they had to use –autorelease syntax to let system manage them. After announcement of ARC (Automatic Reference Counting), most part of the job is done by ARC structure. But this time again, developers have to manage object pointers to help ARC, which is responsible for releasing unused objects. Also ARC introduced another complexity about memory management: strong-weak pointers. With strong-weak pointer distinction, now you have to avoid retain cycles. Avoiding retain-cycles is a little more complicated than manually managing everything when you haven’t made a good design in the beginning.



In contrast to a Garbage Collected environment, ARC immediately frees a memory area when there’s no “strong” reference left to it. Besides, GC scans the heap on unknown intervals to free unused memory, and takes the responsibility of the most critical aspect of mobile development. As an iOS developer myself, I would feel very uncomfortable about this if GC is used on iOS. This inconvenience already makes ARC the best solution to memory management for mobile devices.


All these pitfalls of mobile development are not a problem for Smartface developers. With Smartface framework, we eliminate memory management troubles ourselves. For example; if you are a native developer using mobile device’s camera to take a picture, you will have to be very careful with raw image data. You will try to find a way to release it as soon as possible since it’s very much for your responsive application. But with Smartface, using Image helper functions, all of these will be our responsibility. Images are saved, scaled or even rotated with a single line of code without any memory dubiousness.


Pages, UI objects, network data is mostly created and open place on run-time without noticing the SAS developer. Even if the developer makes junior mistakes such as putting lots of massive sized images in a RepeatBox object, we will try hard to catch native memory-warnings of iOS and -at least- prevent crashing. Also with our object data models in C++ core interface, which stands between the JavaScript engine and native Objective-C code; you will be able to reach the properties of UI objects that aren’t actually exist in memory as a respectable UI object.


But as a JavaScript developer, you will still have some responsibilities about memory management. Since JavaScript has Garbage Collection, you should better keep an eye on the global objects that you have created. I still think JavaScript objects are no big deal compared to million pixels of image data or UI layers drawn on screen, and their effect on your application’s responsiveness will be too little. But if you’re a mobile developer, you should better use every bit of that address space effectively.