Posts Tagged ‘apps’
Supporting Tall Retina Images in iPhone apps
If you have an iPhone app or are developing one, with the launch of iPhone5 , you need to ensure that your images scale to support the new taller retina display (640X1136).
In case of the launch image, naming the new launch with the suffix "-568h@2x" (e.g.. Default-568h@2x) will ensure that the system picks up the right launch image for the iPhone5.
However, just adding the "-568h@2x" to the new images is not sufficient to have the system pick the right images for the tall retina display. Here is a very simple category on UIImage that can be used to return the right image. Note that in the category implementation, I assume that all the iPhone5 specific images are named with a suffix of "-568h@2x".
The "UIImage+iPhone5extension.h" Interface definition
|
1 2 3 4 |
<span style="color: #78492a;">#import </span><UIKit/UIKit.h> <span style="color: #bb2ca2;">@interface</span> UIImage (iPhone5extension) + (<span style="color: #703daa;">UIImage</span>*)imageNamedForDevice:(<span style="color: #703daa;">NSString</span>*)name; @end |
The "UIImage+iPhone5extension.m" file implementation
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<span style="color: #78492a;">#import </span>"UIImage+iPhone5extension.h" <span style="color: #bb2ca2;">@implementation</span> UIImage (iPhone5extension) + (<span style="color: #703daa;">UIImage</span>*)imageNamedForDevice:(<span style="color: #703daa;">NSString</span>*)name { <span style="color: #703daa;">UIImage</span> *returnImage = [<span style="color: #703daa;">UIImage</span> <span style="color: #3d1d81;">imageNamed</span>:[<span style="color: #703daa;">NSString</span> <span style="color: #3d1d81;">stringWithFormat</span>:<span style="color: #d12f1b;">@"%@"</span>, name]]; <span style="color: #bb2ca2;">if</span><span style="color: #000000;"> (</span><span style="color: #78492a;">UI_USER_INTERFACE_IDIOM</span><span style="color: #000000;">() == </span>UIUserInterfaceIdiomPhone<span style="color: #000000;">)</span> { <span style="color: #bb2ca2;">if</span><span style="color: #000000;"> (([</span>UIScreen<span style="color: #3d1d81;">mainScreen</span><span style="color: #000000;">].</span>bounds<span style="color: #000000;">.</span>size<span style="color: #000000;">.</span>height<span style="color: #000000;"> * [</span>UIScreen<span style="color: #3d1d81;">mainScreen</span><span style="color: #000000;">].</span>scale<span style="color: #000000;">) >=</span><span style="color: #272ad8;">1136</span><span style="color: #000000;">)</span> { <span style="color: #bb2ca2;">return</span> [<span style="color: #703daa;">UIImage</span> <span style="color: #3d1d81;">imageNamed</span>:[<span style="color: #703daa;">NSString</span> <span style="color: #3d1d81;">stringWithFormat</span>:<span style="color: #d12f1b;">@"%@-568h@2x"</span>, name]]; } } <span style="color: #bb2ca2;">return</span> returnImage; } @end |
Just include the above files in your project and replace relevant occurrences of [UIImage imageNamed:] call with [UIImage imageNamedForDevice:]. This would ensure that right image is picked up for non-retina,retina and tall retina versions of the resolution.
Mobile Web Apps or Mobile Native Apps?
This is probably one of the most commonly asked questions by folks looking to mobilize their business (probably right after what mobile platform to target).
While I have discovered a lot along the way from my own experience as a (native) mobile developer, I must add the disclaimer that this blog is also a result of discussions with a lot of smart people in this space. I thought it would be worthwhile sharing it to a potentially larger audience.
Definitions
First , a brief definition of the two- [Mobile]Native Apps are mobile applications that can be downloaded and saved onto your mobile device from where they can be loaded to run natively on your device. [Mobile]Web Apps are mobile applications that are hosted on a remote server from where they are loaded and to run within a web browser environment on your mobile device.
The list below is by no means exhaustive. It is an attempt to highlight the major advantages of the two
Why a Web App?
1) “Develop once, Run everywhere”
This implies that the web app is for most part platform agnostic. This has been widely touted as the selling point for web apps, however the statement is not entirely true. HTML5 is still in the process of standardization (http://dev.w3.org/html5/spec/Overview.html ) and as we know all too well, despite standardization efforts, ,there will undoubtedly, be variations in browser implementations across platforms. These variations will impact the behavior, performance and appearance of your web app on the various platforms. Still, while I cannot quantify this statement, one can infer that the development effort/cost will be lower than building native applications independently for each of the platforms of interest.
2) App is primarily “network data driven”
By this, I mean that the app communicates heavily with backend data servers for its various functions. Communicating large volumes of data across a bandwidth constrained wireless network is not practical (unless you have a cheap, unlimited data plan – if there is such a thing!). In this case, hosting the app in the network in the proximity of the servers will alleviate the problem.
3)Application developers want to “be in greater control”
Today, the fate of the apps is dictated (to a large extent) by the terms and conditions imposed by Apple App Store , the Android Marketplace or any of the other app storefronts. As an example, Apple’s “subscription model” imposed major restrictions on in-app purchases made from native apps which led many app developers to remove the “Buy button” from their apps. Web apps will allow you to bypass those restrictions allowing consumers to directly make purchases from their web apps. This provides developers the flexibility they need to deliver the desired service to their consumers without being encumbered by policies set forth by the application store owners. That said, while there isn’t a concept of a “web app storefront” today, one can envision that something like that would be in place when web apps become more ubiquitous. So it remains to be seen if there would be any restrictions that can impact the services rendered by web apps.
Why a native app?
1) Performance, Performance, Performance!
This statement probably needs no further explanation. If performance is an important criteria, which is typical of game apps, then native app is the way to go
2) Superior User Experience/ Interface
Native Apps leverage the hardware acceleration support for graphics available through specialized GPUs and use customized/optimized platform-specific graphics libraries , thereby resulting in a vastly superior UI experience that is hard to match by web apps using JS/HTML/CSS. I earlier mentioned “Develop once, Run Anywhere” as an advantage for web apps- However, if UI is an important consideration for your app, then note that the same “one size fits all” model will result in a sub-standard user experience on certain platforms and this would be unacceptable to users who are used to a particular level of user experience on a given platform.
3) Support for Remote Notifications
Most platforms provide some sort of remote notifications framework (eg- Apple’s PUSH Notification Framework, Android’s C2DM ) that allow registered apps to receive asynchronous from their application servers via centralized notification servers. Only native apps can register for push notifications. If this is a requirement for your app, then native apps are definitely a better fit. Alternatives for web apps like SMS or emails are not as seamless or compelling.
4)No Network Connectivity
If your app does not require network connectivity for its various functions, then offering it as a web app would impose that unnecessary requirement for it to run. Of course, HTML5 supports Application Caching that can be used to locally cache apps and run it even without a network connection. So this is probably not an issue, but the level of support may vary depending on the browser’s HTML 5 implementation.
5)Better Hardware Access & Control
Native Apps can access and control platform hardware resources like camera, accelerometers through native APIs exposed by the platform. This can be leveraged to build unique, compelling features into the apps. Although HTML5 is aimed at standardizing access to various hardware resources on the platform, the level of support is likely to be “inferior” compared to the options available to Native Apps – and by ”inferior” I mean that the platform vendors are more than likely to support access to a particular hardware resource natively prior to supporting it on their browsers. In some cases, the vendor may choose not to (for security reasons) provide access to certain hardware resources via their browsers. Besides, the level of hardware access support can vary across browser implementations.
In Summary..
There is a place for both types of apps out there. The choice greatly depends on the objective of the application and the targeted audience.
Handling ToDo(s) and FixMe(s) in your code…
No comments
As an iOS developer (or any developer for that matter), it is not uncommon (or dare I say- its “very common”) for us to defer things while coding so as to not disrupt the current coding flow. For instance, handling of a special case or updating an algorithm with a more efficient one or just a reminder to double check a certain logic . To remind ourselves, we typically include a comment like “ToDo: Handle error code -1020” in our code.
Now, before we realize it, we have several “ToDos” and “FixMe” scattered throughout our project and unfortunately, many of them go unattended . Note that “attending” to them may be as simple as removing the comment because we have in fact handled the “To Do” but have just forgotten to remove the now obsolete comment which leads to clutter and confusing code.
So here is a neat little perl script that I found (and tweaked a wee bit for my purpose) that solves the problem. The script is executed every time my project is built. The purpose of script is simple. The script greps for keywords in all the .h and .m files in the ${SRCROOT} folder and prefixes it with a “warning” label.
Now, every time, I compile my project, the script runs and displays all statements that begin with keywords listed in the KEYWORDS reg expression show up as warnings. They are now hard to miss and I can ensure that all the “To Do”s are handled in a timely manner.
Then , cut and paste the script to the “Run Script” section
Now, when you build your app, you should see all comments that include the keywords mentioned in the script listed as warnings.