Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Zendcon 2012 - Going Mobile with ZF2

Zendcon 2012 - Going Mobile with ZF2

This session goes through the several tactics that you may take from a ZF2 point of view and how you might incorporate going mobile with your website.

Mike Willbanks

August 28, 2018

More Decks by Mike Willbanks

Other Decks in Technology


  1. 2 •  Talk  Slides will be posted after the talk.

    •  Me  Sr. Web Architect Manager at NOOK Developer  Open Source Contributor  Where you can find me: •  Twitter: mwillbanks G+: Mike Willbanks •  IRC (freenode): mwillbanks Blog: http://blog.digitalstruct.com •  GitHub: https://github.com/mwillbanks Housekeeping…
  2. 5 A Definition Form Factors of web sites need to

    change; luckily we’re not in the days of these phones anymore!
  3. 6 Mobile is everywhere! • From laptops, tablets and smartphones  Who

    has all 3? • Typing is more difficult on tablets and smartphones  Unless of course you have a keyboard for your tablet. • Everyone wants to be able to access anything, anytime, anywhere.  And you need to let them!
  4. 7 Websites, Apps and more oh my! • Implementations…  There is

    an app for that! • Native? HTML5? • iOS, Android, Windows Mobile, Blackberry?  There is a website for that too! • Main website • Mobile website
  5. 9 • Do I  Build out one size fits all?  Build

    out a mobile version? • Do I use responsive techniques? • Do I change layouts? • Do I change the information?  Build out an app? • HTML 5 or Native? • Use a framework? Titanium, Phonegap, etc? So many different approaches
  6. 10 • Designing a single website for multiple form factors • Generally

    done by using a responsive framework  Twitter Bootstrap does this J • Pros  Generally faster to develop.  Eases layout issues to get something to production quickly. • Cons  Not fully mobilized  Still downloads items potentially not needed. Responsive Design
  7. 11 • Designing a single website for multiple form factors • Individual

    pages are different based on device and/or type. • Pros  Generally a better user experience. • Cons  Additional work to create separate layouts and views.  May still have backend work that you are not leveraging.  May contain routes that are unnecessary for a mobile experience. Separate Layouts and Views
  8. 12 • Designing a single website for multiple form factors • Individual

    pages are different based on device and/or type. • Pros  Completely customizable website and fully separate. • Cons  Far more work.  Must customize how your traffic may flow. Separate Site
  9. 15 • Satisfies a Business function  Function broken into Tasks • Easy

    consumption by your application • Allows vast re-use and more generic implementations • Decoupled to represent more or less a single item • Application logic becomes more encompassed  Filtering  Validation  Transactions / Interactions between Domain Models A Service
  10. 17 • A domain model is a representative entity of “something”

    that solves a domain problem. • The entity is NOT explicitly tied to your database. • The entity essentially contains getters and setters for properties and potentially some behaviors. Domain Models aka Entities
  11. 19 • A data mapper handles the communication between the data

    source and the population of an domain model.  In a ZF context this is generally fetching data from Zend\Db \TableGateway. • Extremely flexible and easily handles if the underlying data changes.  Alternatively; when you now have separate tables that still can represent the same domain model. Data Mapper
  12. 21 • Persistence… you need to store it somewhere! • Data may

    come from several places…  File System  Web Service  NoSQL DB  Relational DB • If you utilize an ORM this is also where it would live. • If you’re looking for a sweet library  http://contain-project.org/contain  Tweet @andrewkandels Data Store
  13. 23 • Several different techniques  WURFL – based on capabilities • Free

    BUT non-open source license. • Learn more about the PHP API: http://wurfl.sourceforge.net/php_index.php  preg_match – based on user agent only\  Likely to be a better way • Just not coded yet. Mobile User Detection
  14. 24 • To achieve separate views between mobile users and non-

    mobile users  Change the default suffix of the template path stack. Changing Default Suffixes
  15. 26 • Changing the template is sometimes a valid area  The

    content you have is fine but the template is too much. Changing Templates
  16. 28 • Do you need to do specific mobile work in

    a controller?  Same type of thing as before; except we can change the view if need be. Manually within a Controller
  17. 30 • Sometimes you may want a mobile specific website  m.yourhost.com

    • Incorporating into a separate module • Can do through routing! Completely Separate Website
  18. 32 • You remember the service objects from earlier? • Implementing API’s

    based off of your service classes can be easy! • ZF Built-ins  SOAP Server  JSONRPC Server  XMLRPC Server Attaching Services
  19. 34 • If you do RESTful implementations for your API  AbstractRestfulController

    OR RestfulController What about Restful implementations?
  20. 36 • Leverage Zend_Mobile from ZF1 (1.12)  Hopefully going to port

    over soon to ZendService components. • Quick Primer into looking at Push Notifications Push Notifications
  21. 46 • There are several strategies to mobile • Each has their

    pros and cons • Utilize which methods work best for you. Recap
  22. 47 •  These slides will be posted to SlideShare &

    SpeakerDeck.   SpeakerDeck: http://speakerdeck.com/u/mwillbanks   Slideshare: http://www.slideshare.net/mwillbanks   Twitter: mwillbanks   G+: Mike Willbanks   IRC (freenode): mwillbanks   Blog: http://blog.digitalstruct.com   GitHub: https://github.com/mwillbanks Questions?