1. Error Handling?
A safe net when something goes south. I do find this gives a better context in error handling and better readability.
What is try! and try?
Use try! when you need to ensure your app always succeed as in won’t throw an error, but when it really does, your app shouldn’t work.
try! before the expression to disable error propagation and wrap the call in a runtime assertion that no error will be thrown. If an error actually is thrown, you’ll get a runtime error.
try? to handle an error by converting it to an optional value. If an error is thrown while evaluating the
try? expression, the value of the expression is
Continue reading “10s of How to use …”
There’s no complex app that is completely bug-free. We need to debug not only logic flow but also user interface to make sure our app is okay. By debugging it under different environment or investigate reported issues, we try to make our app’s unwanted behaviour as low as possible.
I usually use this to test work flow and make sure the app logic is working as intended. For example the app is supposed to go into Loop A and stop at condition B rather than condition C, using breakpoint make it a lot easier to do so.
Way 1 : Xcode > Code Left (where you can see your line no.) > Click on it and you will see a blue arrow appear) > Breakpoint at the position you want > Run the simulator and see if it stop at the blue arrow position
Continue reading “Xcode Debugging Skills”
Nowadays even though Apple does not really support sidebars as they encourage tab instead but a lot of apps still prefer to use this approach. There are a lot sidebar libraries in cocoapods but in the end I choose:
ECSlidingViewController is a view controller container that manages a layered interface. The top layer anchors to the left or right side of the container while revealing the layer underneath it. This is most commonly known as the “Side Menu”, “Slide Out”, “Hamburger Menu/Drawer/Sidebar”, etc…
*image source here*
Continue reading “ECSlidingViewController for sidebar”
*photo credit from http://spin.atomicobject.com/*
For a simple project, it is ok to use one storyboard(with 5-10 view controllers) but imagine the project is getting bigger and there are 3-4 developers working on the same project and there are 10-20 view controllers.. your storyboard will turn into monster! From one storyboard splitting into multiple storyboards can be helpful and you can (try to) avoid conflicts in storyboards happen in between programmers when commit to the your project repository. By splitting them up, you have a better visibility between view controllers thus faster understanding for programmers that just jump into the project as well.
Continue reading “Consider Multiple Storyboards?”
Realm is still in its development phase where it have its limitations but somehow after I’m getting more and more familiar with Realm, some essentials must have issues in Realm are still unavailable today (23May2015). Therefore at current stage I might need to use some outsider extension on Realm for my needs.
For my early post on Realm, please refer here.
Example table scheme:
Continue reading “Realm Limitations”
Sorry for the child-like layout to describe the scenario. When user tapped navBar, the dropDownView will be toggle to show or hide.
DropDownView is positioned behind the navbarview in storyboard but I need to recalculate the height and position again because my dropdownview content changes dynamically from time to time.
Continue reading “Swift DropDown View Animation”
I have once dreaded to implement SNS because it is troublesome for programmers but according to current trend, majority users has SNS and it will provide a lot of convenience to them. For client, they deemed it is a “IN-thing” to do. For my current app, I have to implement 4 SNS platforms (and traditional username & password login).
Data that I retrieve from account:
- Firstname/ name
- Lastname (Optional)
Continue reading “SNS Login with Swift”