Τρίτη, 16 Σεπτεμβρίου 2014

How to keep your view controllers small for a better code base

source: 

iOS apps are built according to a widespread programming pattern: the model-view-controller pattern (or MVC). The MVC is a high-level pattern used to describe the global architecture of an application and to classify objects according to the general roles they play. In MVC objects tend to be more reusable and programs are more easy to change.
In the MVC pattern objects are subdivided in three categories. Model objects encapsulate the app data and the logic to manipulate them. Model objects have no explicit connection to the user interface or knowledge of it.
The user interface is represented by view objects. The role of these objects is to present information to the user. They know how to display data and might allow the user to interact with it, but are not responsible for its storage.
What ties these two layers are controller objects, making sure that views have access to the model objects they need to display, and propagate changes in both directions. Because of this role, they tend to be the least reusable objects in an app architecture.
iOS uses a special kind of controller objects, called view controllers. These special controllers don’t only take part in the MVC pattern by mediating between the model objects and the view objects, but also take additional responsibilities. One of these responsibilities is that they are, like views, part of the responder chain, so they receive events too (like, but not limited to, touch events). View controllers also receive memory warning notifications from the OS and are responsible of memory management.

The problem of massive view controllers

Since view controllers have additional responsibilities in iOS, they have to handle quite a load of work. For this reason it is really easy for other code that would not belong to view controllers to creep inside of them. So they often become big monoliths, containing all sort of functionality, because it is easier to just add another method to a view controller, until you find yourself with a bloated object that becomes really hard to modify or refactor, making view controllers even less reusable than they would be. This is why they are jokingly called “massive” view controllers by developers.
I know this firsthand, because I’ve been guilty of this behavior and I still prone to it, despite being here telling you to avoid it. It’s something so ingrained in the way we make iOS apps that it requires developers to be constantly vigilant to avoid it. I personally use lines of code as a metric to measure if a view controller is growing too big. If a view controller goes above 500 lines it means that it is probably including functionality that should not be there, so I review it  with more attention.
Try not to let a view controller grow too much before refactoring it. Although it’s true that you can always extract functionality from it later, if you keep postponing it, all the code you write in a view controller is going to be entangled to some other code, thus making it harder to extract it. Also, there is usually the psychological barrier of not wanting to go into big refactorings and touch code that already works for fear of breaking it.

How to write smaller view controllers

There are a few guidelines I follow to keep my view controllers small and manageable and they all come from the role a view controller has in the MVC pattern, which is to only allow transition of information between the model and the views. View controllers, due to their special role in memory management, can also perform set-up and manage the life cycles of other objects.
The domain (or business) logic for an app is not listed in these duties. This is the first place where actually code that should not be in view controllers creeps in. View controllers often take part in the business logic of an app, manipulating objects, incorporating algorithms, dealing with the network or the disk. They in fact absorb most of the code that should go into the model layer. This is all logic that should be put into separate, specialized classes, while the view controller itself should only initiate changes responding to user input.
A specific case for this is represented by delegates and data sources. In iOS, complex views like table views or collection views, get configured by external objects, called delegates and data sources. Very often this functionality is implemented inside view controllers. This happens a lot also in many tutorials and even in Apple documentation. There is even a specific subclass of UIViewController, the UITableViewController class, that automatically sets itself as the delegate and data source of its table view.
A better approach here is instead to actually separate these behaviors into separate classes. The data source is especially a very good example for this. If, for example, the data for a table view is provided through an array, as often happens, you can write a data source objects that handles the array and provides all the behavior specified by theUITableViewDataSource protocol: returning the count of the array as the number of rows in the table view, fetching the object at the appropriate index when the table view requires it, inserting and deleting objects in the array and so on. This removes a lot of code from a view controller and has also the benefit of being much more reusable: the next time you will have a table view that gets filled by an array of objects, you will have to just create a new instance of your array data source, assign it to the table view and you are done. This data source class is even portable to other apps. You can have a data source to deal with Core Data, or a data source that deals with objects fetched from the network. Once you have written and tested them, they will be readily available to all your future apps. In addition, your view controllers become more general themselves and can be reused with different kinds of data sources across your app.
The other side from where unrelated code creeps in a view controller is the UI side. Many times view controllers get hooked through outlets to every single view on the screen and then proceed to set their appearance and position. But this is actually code related to presentation, so it is better to isolate it, for example in subclasses of UIView. Your view controllers will be again smaller and more general, and these views that you create might also be reused in other parts of the app or other apps. After all, this is exactly what a table view already does: incorporate specific UI code so that you have a ready to use component that you can use in many different places.
Speaking of table views, another place where UI code creeps into a view controller is when dealing with table view cells. The culprit here is the -tableView:cellForRowAtIndexPath: delegate method. In this method, model objects get fetched from the data source and used to set the content of table view cells, either through outlets or, even worse, accessing the cell subviews directly using the -viewWithTag: method of the UIView class. Unfortunately this code is even present in the Apple documentation, so many people follow it (I did that in the past too, not knowing any better). What should really be done here is to create a subclass of UITableViewCell that takes care of populating all the cell fields. In this way the -tableView:cellForRowAtIndexPath: will only have to fetch a record from the data source an pass it to the cell, which can be done in just two lines of code. By the way, as you might have noticed, the cell itself becomes is a more generic and reusable class. Once you have created a custom class for your table view cells, other logic will fit in it naturally, like, for example, calculating the cell’s height when it is dynamic.

Δευτέρα, 24 Μαρτίου 2014

User Experience - user experience design

UX
In most cases, user experience design (UXD or UED) fully encompasses traditional human-computer interaction (HCI) design, and extends it by addressing all aspects of a product or service as perceived by users.[1] User experience is any aspect of a person's interaction with a given IT system, including the interface, graphics, industrial design, physical interaction, and the manual.[2]


  • Deliverables Vs Delivery: create prototypes-diagrames etc but ALWAYS check the feedback (talks, surveys,tweets, reactions etc). 
  • CONSTRAINTS FUEL CREATIVITY: don't make something for all. Create something to be loved from a specific audience. Example iPad lacks usb-extra cards etc for geeks but loved for kitchen or bathroom use from typical non laptop users. Do not create something for you. UX designer is not the center of the universe. The Specific user is. Embrace the constraints. 
  • UTILITY VS. BEAUTY: do not create beautifull thinks for beauty, but make utility to be elegent and beauty. 
  • THE USAGE LIFECYCLETake the time to understand your user. It will decrease the risk of creating an an unfavorable experience and give you an opportunity to turn them into your greatest advocate.Do that through life cycle (First Contact,First Time Use,Ongoing Use,Passionate Use,Death).
  • MAKERS OF FRAMES: 
    • structural frameworksEating in the dining room is the best…eating in the bathroom is…not such a good experience. We build rooms->web pages. 
    • Visual Frameworks: visual hierarchy 
    • Social Frameworks: poke, favorite, ...
    • Conceptual Frameworks:clarity, brand
  • USER INTERFACE AS CUSTOMER SERVICEuse microcopy.  
  • VISUAL HIERARCHY - The best visual hierarchies lead users to take the action confidently
  • VISUAL WEIGHT - Visual weight reinforces a page or screen’s visual hierarchy by contrasting the size, color and/or position of elements in the design.Color is another key in establishing Visual Weight.
  • It's the little things: Charles Eames said, ”The details are not the details. They make the design." 
  • Honest Interface: The integrity of the interface reflects how much you value your users. 
  • 10 UX principles 
    • The Experience Belongs to the User
    • UX is Holistic
    •  Great User Experiences are Invisible
    • UX is a Lifecycle
    • Context is King
    • Great Experience is about Control
    • UX is Social
    • Psychology is Primary (psychology of use, play, product adoption, and social interaction to create the best experiences)
    • UX is a Conversation (The conversation is both how we deliver and how we find out how to make it better)
    • Great Experiences are Simple



Τετάρτη, 19 Μαρτίου 2014

udemy - ios7 full curse only for 19$ .. for few hours

I think is good value for money 19$ for 400 lectures - 33+ hours video.


more info here

The Complete iOS 7 Course - Learn by Building 14 Apps

Over 350+ videos taking you step-by-step through process of building 14 different applications in iOS 7 and XCode 5.
53 reviews
Our iOS Bootcamp teaches the tools needed to develop iPhone and iPad applications for iOS7. Along our journey, we will learn the syntax of Objective-C, the language used to develop for iOS, as well as important design patterns and best practices. By the end of the course, you should be able to understand and recreate many of the features seen on popular iOS applications and extend that knowledge to making apps of your own.
We believe students learn by building. That's why we have you build 14 apps during the course, with the final app being a full featured dating app: A Tinder Clone!
Topics Covered:
  • Objective-C: Learn the language used to develop all native iOS and Mac apps
  • Parse: A revolutionary new tool that allows iOS developers to create a server side in Objective-C
  • iOS7 and XCode 5: Learn the latest technology platforms from Apple
  • API Integration: Connect with third party APIs like Facebook, Foursquare and more
  • Storyboard: Learn how to create beautiful interfaces using Apple’s graphical interface builder
  • Core Data: Store data on your device with the core data database
  • Git: Learn how to us Git for version control and collaboration
  • Mixpanel: Integrate analytics into your apps
Reviews

Δευτέρα, 13 Ιανουαρίου 2014

Τρίτη, 17 Δεκεμβρίου 2013

Flesky Keyboard (for developers also)

http://vimeo.com/75453371

Get Fleksy SDK for your iOS app

Fleksy is the first keyboard app to arrive on the iOS platform. If you are an iOS developer you can now choose to integrate Fleksy’s SDK as an additional keyboard in your app.
Fleksy’s award winning keyboard has over half a million users on iOS already, using our stand-alone app to input text and send it into other apps.
Up until now, iOS limitations made it impossible to replace the default keyboard on iOS devices.
Integrating the Fleksy SDK means that users can now type with Fleksy’s keyboarddirectly in your app. 


Κυριακή, 15 Δεκεμβρίου 2013

11 Things You Must Know When Starting Out in iOS/Mac Development (copy - paste)


From a good article in Gibbon (http://www.appdesignvault.com/start-advice/
  1. Don't expect overnight success - Tweet this
  2. It's never been easier to make amazing apps, if you are considering it: go for it!
  3. Don't target a niche that will only pay 99c for your app.
  4. Hire a designer
  5. Don't lose faith, take more risks!
  6. Give back. The fastest way to learn is by openly sharing and discussing ( Asymco.comben-evans.com and listening to The Critical Path.)
  7. "Don't believe everything you think."Don't fall in love with your ideas. Always look for ways to prove yourself wrong
  8. Don't build an app thinking you will find an audience later, find the audience first and then build apps to meet their needs
  9. For this to be an enjoyable living you need the enjoy the process and people involved.
  10. Sometimes having less features can be your biggest competitive advantage
  11. Don't be afraid to meet new people. Work to overcome your introversion. 

CocoaPods - NSScreencast - NSHipster


https://gibbon.co/pinda/ios-development/13-things-you-must-know-when-starting-out-in-iosma?playlist=dfb846a8-8d94-4e3b-9fc0-647853072aa3
Mattt Thompson
Creator of AFNetworking & NSHipster������
  • It's never been easier to make amazing apps, if you are considering it: go for it!
13 Things You Must Know When Starting Out in iOS/Mac DevelopmentWhen I first started iOS, I had been a Ruby & Rails programmer for about 4 years. I definitely spent a lot of time grappling with the language syntax, and trying to get a handle on all of the system frameworks. Back then, tutorials for basic tasks were sparse, and there were almost no open source projects to speak of. I had to rely on Apple's sample code and shear determination to get anything to work.
But still, just the novelty of being able to create something for the iPhone was enough to make everything worth it. These days, I'm happy to say that an iOS developer starting out today has dozens of great resources and hundreds of open source libraries available at their disposal. For tutorials and sample code, I heartily recommend Ray Wenderlich's site &NSScreencast. For anyone wanting to learn about more advanced topics, I write about obscure parts of Objective-C and Cocoa every week onNSHipster.
As far as open source, CocoaPods is absolutely essential. Not only does CocoaPods make managing dependencies effortless, but it's become an amazing tool for discovering new libraries. So much has changed since I first started out. It's never been easier to get started and make amazing apps, so my advice to anyone starting out or considering iOS development is simple: go for it!