Presenter: Kyle Browning, Workhabit
Why NOT native?
- Options like Titanium/Appcelerator support multiple devices
- Rapid prototyping: it’s easier to write JS than to do a bunch of memory management stuff
- Native is not easy for development.
WHY native
- Faster performance on the device
- supported by the OS maker (can make support requests on iOS/Android forums)
- Manage errors on the side of the stack
- No waiting on API updates, release schedule
- Game development
- Personal prefs
Dev process
- Start with getting your idea on paper.
- Getting the idea on paper helps the entire process go more smoothly
- Build wireframes/prototype
- It’s easier to fail in wireframes and prototyping
- Gather all the types of content you’ll be using
- Lay out the app in a workflow (user flows, task maps)
- Use tools like Briefs, Omnigraffle, Axure
- Save time on development by failing early and learning as you go
- Design (visual, UI)
- WIll it need to support multiple devices?
- What are the key tasks and how will those be called out
- Attempt to create an experience users are familiar with: colors, taxonomy menu, etc.
- Development
- Figure out what features are pre-reqs for others
- Will content come in as feeds? First build content, then feeds or vice versa
- Build API communication file
- If things are constantly changing, write unit tests
- Tackle the larger, harder problems FIRST
Mobile stack
- Mobile App
- Services
- Standardized solution to integrate external apps with Drupal
- Service callbacks can be used with multiple interfaces like REST, XMLRPC, JSON, JSONP, JSON-RPC, SOAP, AMF, etc.
- Gives you your connection into Drupal
- Much time is spent messing around with Services
- Servers
- Defines Accept and Response types
- Call Authentication Methods
- Executes the actual function call
- Authentication
- Session based
- OAuth both 2-legged and 3-legged
- Singletons: You’ll have a user object that exists through the entire app; you want to make sure that only that object exists. Singletons help with that.
- No need to re-login to the app when it opens.
- Endpoints
- A URL that a mobile app will hit
- The bread and butter of Services
- It’s a configuration object that has all the resources and servers/auth methods, etc. that you need to make Services work.
- You can also work with versioning, access controls for new developers, etc.
- Versioning
- Helps keep things consistent
- Won’t break apps when you build new features or functionality
- Things to note:
- Services Views is a bit wonky, but it works
- There is potential to break if you change Views
- Features allows you to take the View and put it into code so that it can’t be messed with.
- Adding images inline within content
- Services will insert unnecessary HTML tags instead of images
- Working on a module that will strip out images and attach them as a file to the node
- Use Imagecache to deal with image handling (it’s already in D7 Core)
- Tools
- Drupal iOS SDK and Dandy
- Sits between Services and the mobile app so you can communicate with Drupal natively
- Helps do user/session management
- Services Log
- hooks into services and logs everything that Services is doing.
- You can see when you’re getting a 403, etc.—what is messing up and why?
- Drupal
- Holds and organizes content
- Can be sent to mobile app through Services