Category Archives: native

What’s the deal with Swift?(in my best Seinfeld voice)

swift-banner.png

1)The first big thing that comes up in almost every article I’ve read is that Swift isn’t finished, it still has important features that are actively being built and tested.

Example from the Huffpost article linked below, author Ahmed Eid states “ Currently in Swift, anything you declare in any class is automatically public and available to every other class. At one of the labs at WWDC, we asked an Apple Swift engineer if it’s possible to make a property private, (that can’t be altered from a different class), and we were told that this is indeed coming in the next few months”. (as of 6/13/14)

Programs written in Swift also cannot be released until Xcode 6 is ready, which is still in beta and won’t be ready before iOS 8 / Yosemite ships.

source: http://www.huffingtonpost.com/ahmed-eid/apples-swift-is-great-but_b_5492239.html

2) Swift can be experimented with in an interactive environment called “Playgrounds”. This tool allows the programmer to view the effects of changes or additions to code as you type, without having to run and execute code for every change.

3) The continued importance of objective- C when working with Swift:  If you want to use C/C++ libraries in Swift you will still need to talk with the libraries using OB-C. Apple made it possible for Swift and OB-C AND C++ to all coexist in the same app, so a given program could be written in 3 different languages.

4) The frameworks are written Objective-C. A programmer might have a hard time finding bugs until execution is deep in Apple’s code. If you want to understand what the debugger is telling you, you will need to understand Objective-C.

source: http://www.bignerdranch.com/blog/ios-developers-need-to-know-objective-c/

This bignerdranch article also talks about which program may be easier to learn. The author states that having a solid foundation in Objective C will make learning Swift much easier!

5)  Nitty Gritty: Technical differences of Swift

A) Type Inference: Programmer doesn’t need to annotate variables with type       information. The compiler infers it from what value is being set to the variable.

B) Generics: in which algorithms are written in terms of types to-be-specified-later that are then instantiated when needed for specific types provided asparameters.

C) Containers: In Objective-C, arrays and dictionaries can contain any type you want. But in Swift, arrays and dictionaries are typed. And they are typed through the use of Generics.

D) Mutability:. There are no “mutable” counterparts to Array and Dictionary. A programmer will use the standard let and var. Let is used to declare a variable as constant, and var is used to declare a variable as a variable. Let is like using const in C/C++/Objective-C.

E) String functionality:Swift makes dealing with strings much easier to handle. For example,  you can concatenate strings easily using “+=” and compare strings using “==” instead of the having to type out “isEqualToString:”. Strings can also be used in switch statements.

F) In an article published by Javaworld, which is linked in the sources below,  author Paul Rubens explains another big change for Swift,  Tuple’s: “ A tuple lets you group multiple elements into a single compound variable. The values in a Swift tuple can be of any type and don’t have to be the same type as each other. You can make a tuple from any permutation of types that you like: (Int, Int, Int) or (int, String) or (String,Bool) or whatever else you need. There are a number of ways to get the values in a tuple. You can access them by index number (starting with 0), for example, or you can decompose a tuple into separate constants or variables.”

G) Control Flow: The switch statement has been significantly updated in Swift and can now match against ranges, list of elements, boolean expression, enums amongst others. It doesn’t fall through by default, and is further enhanced by Swift’s flexible pattern matching.

H) Optionals: An optional type is a type that might contain a value of a type. It allows you to more easily convert between types and avoid null checks. Optionals can be chained together to protect from exceptions when calling multiple methods or properties in a chain where one call might return “nil”.

sources:

http://www.raywenderlich.com/73997/swift-language-highlights

http://www.cio.com/article/2456100/mobile-development/10-things-you-should-know-about-apples-swift.html

http://www.theguardian.com/technology/2014/jun/06/swift-developers-guide-apple-programming-language-wwdc

6)Apple attempts to make Swift a safer language. Programmers must include brace brackets to open and close “If” statements. This change will prevent a variety of  bugs such as theSSL “goto fail” error.  Switch statements also must include a default statement. This will make sure that something will run at the end of the statement even if none of the possibilities in the statement are satisfied.

7)  Apple’s new iOS 8 SDK will include over 4,000 new API’S. From the Apple link below, these are a few of the new and exciting API’s Swift will offer:

  • PhotoKit, so developers can tap into the power of the same robust framework as the built-in Photos app for faster performance, nondestructive edits and the ability to both read and write to the Photos library;

  • new Camera APIs, giving developers fine grain control over focus, white balance and exposure;

  • CloudKit, a complete and scaleable back-end solution helps developers eliminate the need for writing server code and maintaining servers; and

  • new App Store™ features for developers like app previews and app bundles, the new iTunes Connect with free analytics and TestFlight for beta testing pre-release apps.

  • HealthKit, combines health data to help you take better care of your health

Source: https://www.apple.com/pr/library/2014/06/02Apple-Releases-iOS-8-SDK-With-Over-4-000-New-APIs.html

8) Other Links:

Official apple book on Swift: Free download: https://itunes.apple.com/us/book/swift-programming-language/id881256329?mt=11

Apple Developer Tour of Swift: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html

5 best Swift tutorials: http://www.skilledup.com/learn/programming/5-best-free-swift-tutorials-programming-new-language/

Upgrade Tips for iOS 7.0

I just upgraded 5 of my apps to 7.0 from 5.0 (sometimes 4.x) compatibility. Here are some tips from what I learned:

Handling Different Screen Sizes
To handle the change in screen sizes, 3.5 to 4.0, for each xib, get all elements, and change to autosizing. Anchor to the bottom:

anchor_screen

You can see here I’ve added a 60px delta for converting from 6 to 7, just lowering the element a little more in 7. Totally optional- in many apps I don’t even do a delta, fixing it to the bottom solves all the issues.

To test this, do a build, then click the View for that xib.
On the Identity and Type tab, select “ios 7.0 and later”, and view the change to your elements. They should all remain in the same place.

Create new splash screens, icons, app icons
Baseline, you need to create these icons

  • Icon@2x.png (114.px)
  • Icon.png (57px) *you probably already have this *
  • Icon-120.png (120px)

I added all of these to my project, then assigned the 120px one (the rest auto assign, but not 120) in the App/Project/General Settings:
Screen Shot 2013-12-01 at 3.23.28 PM

You also need to add these default splash screens:

  • Default.png (320×480) – you probably have this
  • Default@2x.png (640×960) – if you have a larger graphic, take a higher res screen otherwise, I expanded my 320×640
  • Default-568h@2x.png (640×1136) – I copied the Default@2x.png. in Paintbrush, create a new canvas of the proper dimensions. Paste splash in it and center.

Drag those to the new project, and they should assign automatically to the proper files in Project/General

Upgrading Frameworks
I regularly use Flurry and Facebook. I had old frameworks and took the opportunity to update them.

  1. Remove references to old frameworks- right click delete
  2. Remove references in Build Settings to header files, pointing to old framework libraries
  3. Comment-out code in my project related to framework ( a few methods, etc.)
  4. Build- should build without errors.
  5. Add new frameowrks in according to instructions, uncomment out the custom methods.

Seems obvious, but many hours were spent getting those new frameworks to build right. The key was to do a good clean remove before every installation.

Facebook changed from a project you dragged into your project, to a real framework, making it much simpler to integrate.

Note on Landscape Orientation and Launching
Here are some quick tips if your application is 100% landscape orientation, like mine were.

  • Load the main view with self.window.rootcontroller = self.navController. In old version I could just set the view to the navController view, now you have to set the rootController.
  • This took me forever to figure out: the launch orientation is the first element in the plist entry “supported orientations”. So if you want it to load right, make sure that is the Item 0 in the array, in the plist. It was documented, but buried.
    Screen Shot 2013-12-01 at 3.36.14 PM
  • There are some new methods in iOS 7.0 for autorotate, but by setting the supported orientations, it loaded all views in my NavController in landscape, so including those were extraneous.

Images in iOS 7.0
Only a few changes in imaging affected my apps:

  • Segmented controller images- I check the iOS dynamically and assign images programmatically, adding:

    self.segControl.tintColor = [UIColor redColor];
    [[UIImage imageNamed:@"fr_flag"] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal];
    [self.segControl setImage:fr_flag forSegmentAtIndex:0];
  • Check all of your imageViews in XIBs, many of them were deleted or floating off the view. I redragged them back on, anchored the autoresize,built, and all was fine.

Native, and Mobile Web


Remember this hybrid- VCR/TV- either the TV or the VCR broke. Hybrid mobile isn’t like this, thank god.

Many veterans of mobile development swear by one or the other. Android native, iOS native, or mobile web. Native development has the benefit of fast response time, cutting edge implementation and features, and a more state-like, application-like user experience. Mobile web has the benefits of being quick to update, without long lag-times in the Store (for iOS).  Web development is an easier-to-find, more accessible skill.

I have done a lot of both, and what I recommend is actually a combination of both native and mobile web. It’s difficult, but in the end you get a combination of those benefits, and, in addition, a single codebase (for mobile web), a quicker timeline to release, and breadth of installation base- iOS, Android, and web.

You split the duties between the development styles as: mobile web does screen activity, basically any displaying of database information, features, most of the guts of the application. The wrapper – the navigation generally, user session information, and any native features such as camera, or audio/mike, are handled by native.

The negatives of mobile web: you are making a REST-like web site behave like a state-like application. This takes some tricky rerouting, making it appear to the user like everything is happening one page (as native does). For native, you have to build a very robust web api interface, and largely not take advantage of caching objects, since you need to refresh frequently.

Once you’re ready to quickly deploy and iterate, a hybrid solution of mobile web and native becomes very seductive.