Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Robust Mobile Clients (v2)

Z
May 31, 2014

Robust Mobile Clients (v2)

Extended Toaster Edition. State Machine Included.

Crafted for mDevCamp 2014

Z

May 31, 2014
Tweet

More Decks by Z

Other Decks in Programming

Transcript

  1. ROBUST MOBILE CLIENT Building clients for distributed scalable systems Zdenek

    Nemec – @zdne Apiary.io Toaster controls that do not break
  2. MOBILE “In 2013, the number one reason APIs are deployed,

    is to support mobile development.” ! – Kin Lane
  3. • Apple reviews every App submission • It takes time

    (~1-2 weeks) • Breaking a client = client users are left in the dark for weeks REDEPLOING CLIENT iOS perspective
  4. • Client resilient to API changes • API that can

    evolve • Tune communication without redeploying clients • Move fast • Less code • Less maintenance • Less worries • Better life and everything* PROMISES * results may vary
  5. • Decouple server and client logic • Do ONLY your

    part • No assumptions about the counterpart’s implementation • No reimplementation of the server logic in client • Server-driven interaction DECOUPLE
  6. TOASTER AUTOMATON Waiting Holding Bread Cooking Finite State Machine Insert

    Eject Cook Eject Set Cook Time •cook time •cook time •cook time Set Cook Time Set Cook Time
  7. • Understands the meanings of • toaster, bread • insert,

    eject, hold, and set cook time affordances • cook time property • Does not understand how toaster works TOASTER CLIENT
  8. ! • Starts in one of the tree states •

    Retrieves available state transitions from the toaster server • Decides what of available transitions to take (or none) • Nothing else! (e.g. assuming how cooking works) TOASTER CLIENT
  9. • Hypermedia Media Type • Representation of a resource •

    properties • affordances • embed idempotent relation entities • HAL+JSON, Siren, Uber, Cj, Verbose … REPRESENTATIONAL STATE TRANSFER REST Architectural Style
  10. TOASTER EVOLUTION Cooking •cook time Set Cook Time • Server

    stops offering set cook time in the cooking state • Client not following available affordances from server will break • Client following available affordances from server will stop showing the set cook time UI controls
  11. TOASTER EVOLUTION Waiting Cooking Insert = Cook Eject •cook time

    •cook time Set Cook Time Set Cook Time • Toaster now immediately cooks after bread is inserted • Client not following available affordances from server will break • Client following available affordances from server will still be able to make a crispy toast
  12. FIZZBUZZ ! • Print numbers from 1 to 100 but…

    • Multiplies of 3 print “Fizz” • Multiplies of 5 print “Buzz” • Multiplies of both 3 and 5 print “FizzBuzz”
  13. • Author: Stephen Mizell (@Stephen_Mizell) • Server knows how to

    calculate FizzBuzz for given number • Server knows what is the next FizzBuzz • Clients may decide what is the step and at what number to end FBAAS FizzBuzz as a Service
  14. COUPLED APPROACH 1: for i in 1..100 2: answer =

    GET /fizzbuzz?number=i 3: print answer • This coupled: • Tied to a particular URL • Iteration implies assumption about the result
  15. COUPLED APPROACH 1: while i < END 2: answer =

    GET /fizzbuzz?number=i 3: print answer 4: i = i + STEP • This coupled: • Duplicates the Server logic (addition) • Keeps track of the end
  16. DECOUPLED APPROACH 1: answer = root.follow(“first”) 2: print answer 3:

    while answer.hasLink(“next”) 4: answer = answer.follow(“next”, step: STEP, end: END) 5: print answer • This decoupled: • No hardcoded URLs • No Server logic on the Client • Completely driven by the Server
  17. DECOUPLED APPROACH • Without redeploying clients • change URLs •

    change the algorithm • control the number of API calls (through embedding) • add / extend or modify the functionality
  18. • http://apiary.io • http://apiblueprint.org • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://apievangelist.com • http://smizell.com

    • http://smizell.com/weblog/2014/solving-fizzbuzz-with-hypermedia • http://words.steveklabnik.com/hypermedia-fizzbuzz • http://petegamache.com/wsrest2014-gamache-slides.pdf • https://github.com/gamache/hyperresource • http://www.slideshare.net/KevinONeill1/hypermedia-for-the-ios- developer-swipe-2012 • http://www.slideshare.net/royfielding/evolve13-keynote-scrambled- eggs • http://www.mnot.net/blog/2011/10/25/ web_api_versioning_smackdown • http://github.com/zdne/fizzbuzz-client REFERENCE
  19. • http://www.flickr.com/photos/polishsausagequeen/2178265710/ • http://www.flickr.com/photos/breannajosephine/5265280328/sizes/l/ • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://techcrunch.com/2014/04/30/facebook-api-guarantee/ • http://comicbook.com/blog/2013/01/31/the-big-bang-theory-spoiler-

    does-sheldon-actually-sleep-with-amy/ • http://knowyourmeme.com/memes/shut-up-and-take-my-money • http://www.kitchenaid.com • http://www.hdwallpapersarena.com/wp-content/uploads/2012/12/ Tesla-Model-S-2013-widescreen-15.jpg • http://www.peer1.com/blog/peer-1-hosting-launches-map-of-the- internet-app • http://www.reddit.com/r/geek/comments/mdf63/evolution/ PHOTO CREDITS
  20. REST • Client–server • Stateless • Cacheable • Layered system

    • Code on demand (optional) • Uniform interface • Identification of resources • Manipulation through representations • Self-descriptive messages • Hypermedia as the engine of application state Architectural Constraints