This was, as usual, a great occasion to hear from the iOS developer world and to exchange ideas with other developers.
In my last post I showed how to write a simple PHP code to send iOS push notification using the HTTP2 protocol.
In order to send a push notification to an iOS device we must contact Apple servers and delegate them to do the work (go to this page to find more details on the entire process).
Some months ago Apple published a new protocol that we can use to contact its servers. The previous protocol (the one we used for years) had in fact some problems. In particular after sending a push, we had to wait at least 1 second for a (possible) Apple response. This is ok if we must send a limited number of pushes, but it is not acceptable when we need to send thousands of that (to send a push to 10.000 users we would wait almost 3 hours, spent almost entirely … waiting and idling!) .
@pragmamarkorg for the good day in Florence. Speakers and developers gave to me more technical ideas and good motivation.
When we develop universal apps, we sometimes need to present modal view controllers (“dialogs”) to the user.
On the iPad the popover is very useful to this aim because the user does not loose the context while reading the content of the dialog or while filling some inputs inside it.
On the other side, the iPhone usually has not enough space to show a popover inside the parent (or “presenting”) view controller (however this is possible now in iOS8). So on the iPhone we may want to present the new view controller in a modal full screen mode.
In iOS8 the code to show a simple alert to the user is completely changed. UIAlertView is now deprecated:
The new class is UIAlertController and it is not complex to use (more in a minute). But we also want to support our iOS7 users, so wouldn’t it be nice to have a single class handling the different code? This is what we are going to create in this post.
In the previous posts we coded a fully functional JSON parser completed with error handling and independent from the source of the data (the reader).
In the parser we used also a custom operator >>> to invoke a function on an optional (if this is not nil) and return the result.
Now we are going to refine it and, in the way, see other custom operators.
Sometimes it happens to me to observe my code and to say: “no, these things should be made differently”. Then I go into “refactoring”. I think this is an important step of every programmer. Don’t be afraid to refactor (don’t listen to the voice inside you: “… don’t touch that code! Nothing will work correctly after changing this single byte …”): code is something always in evolution (and in test …).
Seeing the code of Part 2 I don’t like two different callbacks to be passed to the start method:
In this post we continue the development of a JSON Parser starting from the previous one: Swift JSON Parser – Part 1.
Let us begin handling the “something went wrong” part.
Error handling strategy
Two types of “bad things” can happen:
- The parser has an error before looping on the elements of the array: this can be a reader error or the json returned is not of type [AnyObject?]
- The parser starts but has an error on one of the element inside the loop
This is the first part of a multi-step process in which we will build a JSON parser in Swift.
In this first post we will see, among others, the following swift features in action:
- enum with associated values
- curried functions