Architecture pitfalls in android development
•Download as PPTX, PDF•
0 likes•747 views
What can happen in Android when it comes to a bad architecture and it's problems? Everything about this topic (and how to prevent these problems!) is covered in this presentation.
Recommended
More Related Content
Similar to Architecture pitfalls in android development
Similar to Architecture pitfalls in android development (20)
Recently uploaded
Recently uploaded (20)
Architecture pitfalls in android development
- 1. Architecture pitfalls in Android development. (Why building apps is like building houses) Thomas Krüger
- 2. Overview ● Explanation ● Principles ● Planning matters ● Pitfalls
- 3. ● 2008: Mobile developer ● 2010: Freelancer ● Oracle certified Java Programmer Who's speaking?
- 4. Foreword ● no golden way ● use whatever suits you best ● development "style" has to match ● "architecture" can be short-dated "I don't have a solution but I admire the problem"
- 5. Explanation ● Expose the structure ● hide the implementation details ● Realize all of the use cases and scenarios
- 6. Part of what you should have an eye on: ● Activities ● Services ● BroadcastReceiver ● Content Provider ● Intents (implicit/explicit) ...and Lifecycles Building materials
- 7. Lifecycles
- 8. Proof of concept ● Possibilitycheck ● "Spike"(SCRUM) o no result = alternative needed?
- 9. KISS principle ● keep it simple & stupid! ● Simple 2D Game ● Unity? ● Own OpenGL Engine? ● AndEngine?
- 11. Planning matters ● UML o structure diagrams (i.e. class diagram) o behavior diagrams (i.e. use case diagram) o interaction diagrams (i.e. sequence diagram)
- 15. "A bad foundation may cause a bad architecture"
- 16. 1st: Plan it! 2nd: Implement it!
- 17. ...or else...
- 18. Size of architecture "How big gets your project?"
- 20. DRY principle Don't repeat yourself "every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
- 22. Second System Syndrome "I've always done it this way"
- 23. Look for anti-pattern ● Spaghetti code ● Big ball of mud ● Gas fabric ● God object ● Yo-yo problem ● Magic values
- 24. Pitfalls
- 26. UI Threading ● use (multi-) threading wisely ● use advantage of AsyncTask ● don't leak the context o context as static member = Bad idea! o at least context as composition o "getApplicationContext()" may be handy
- 27. Android's UI ● Don't create UI like in Java (Swing) ● use XML where possible o use LayoutInflater o reusability o divide UI and logic o clear MVP
- 28. Orientation lock Good ● Don't worry about rotation (>lifecycle) Bad ● usablity on some devices ● no distinct layouts (land/port)
- 29. When it's already too late... Rethink Redesign Refactor Release...? Refurbish
- 30. Facade pattern
- 31. Facade pattern
- 32. Conclusion ● don't ignore the principles ● determine the right size ● plan your architecture ● rely on best practices ● dont fear to refactor ● look for pattern ● watch out for pitfalls
- 33. find me on available @ Thank you!
Editor's Notes
- COOL TO BE HERE BLA
- EXPLANATION PRINCIPLES PLANNING PITFALLS
- NO GOLDEN WAY USE WHATEVER SUITS U BEST DEVELOPMENT STYE HAS TO MATCH ARCHITECTURE CAN BE SHORT DATED
- ARCHI = ... Framework Archi - OUR archi Expose the structure / hide the implementation details Realize all of the use cases and scenarios
- ACTIVITIES SERVICES BROADCASTRECEIVER CONTENT PROVIDER INTENTS LIFECYCLES
- LIFECYCLES AFFECT YOUR ARCHITECTURE!!! ACTIVITY = STH LIKE A PRESENTER AS IN MVP YOUR ARCHI STICKS TO YOUR ACTIVITY.. IN A SPECIAL WAY BE AWARE OF YOUR CONTEXT!
- LETS MAKE A 100 STAGE HOUSE! YOU WOULD NOT BUILD A HOUSE WITHOUT AN APPROPRIATE PLAN! check of possibility Spike: simple prototype, no result in timebox: alternative?
- DONT REINVENT THE WHEEL IMAGINE U WANT 2 DEVELOP A SIMPLE 2D GAME WICH TECHNOLOGY WOULD U CHOOSE? CANVAS? UNITY? OWN ENGINE? OR ANDENGINE?
- GAS FACTORY U WONT BUILD A SMALL HOUSE WITH A HUGE CRANE, RIGHT? BUT IN SOFTWARE DEVELOPMENT IT OFTEN HAPPENS
- A LOT OF DIAGRAMS DIVIDED INTO STRUCTURE BEHAVIOUR INTERACTION DIAGRAM USE WHATEVER SUITS U (FOREWORD)
- I USUALLY START WITH... GET AN OVERVIEW OF ALL POSSIBLE ACTIONS
- LETS GET TECHNICAL CLEAN UML = CLEAN ARCHI JUST RECOMMENDATION
- MAY LOOK CONFUSE STILL CLEAN, LOOSE COUPLING
- CLEAN UML FROM THE BEGINNING LEADS TO CLEAN ARCHI LEADS TO LESS BUGS IN FINAL PRODUCT ....in THEORY =D
- PLAN EVERY NEW PART (in a big project)
- THATS WHAT MAY HAPPEN IF U JUST HACK
- DETERMINE SIZE HACKATHON SMALL APP HOBBY PRIVATE APP ANTI PATTERN "GAS FABRIC" -> small problem > big archi
- PROFESSIONAL APP CORPORATE APP BIG ARCHI = MORE PLANNING
- MODEL DRIVEN ARCHI WICH MEANS: COPY N PASTE IS EVIL! REPETITION LEADS TO INCONSISTENCY
- HAVE U SEEN A HOUSE WITH DOORS INSTEAD OF WINDOWS? DONT OVER-REUSE STUFF
- DOESNT MATTER WHATS REQUIRED OVER-REUSAGE
- SPAGHETTI CODE: NO STRUCTURE BIG BALL OF MUD. NO ARCHI GAS FABRIC. A LOOOOOT OF CODE ... FOR NOTHING GOD OBJECT. ONE OBJECT DOES IT ALL YOYO PROBLEM: FLIPPING THROUGH CODE WITHOUT CONCEPT
- AS OF HASANS SESSION YEASTERDAY SPEED / RESOLUTION GAME DEV BEST PRACTICES!
- USE MULTI THREADÍNG WITH CAUTION ASYNC TASK IS A COOL WRAPPER DONT LEAK THE CONTEXT
- DONT CREATE UI LIKE IN "NORMAL JAVA" XML AND ANDROID MVC IS GREAT; COOL REUSAGE DIVIDE UI AND YOUR LOGIC
- DONT WORRY ABOUT ROTATION USABILITY SUCKS ONE SOME DEVICES NO DISTINCT LAYOUTS FOR LAND/PORT
- RETHINK REDESIGN REFACTOR REFURBISH RELEASE DONT FEAR TO REFACTOR
- RED CRINGLE
- GET BAD ARCHI CAPSULATED
- don't ignore the principles determine the right size plan your architecture rely on best practices dont fear to refactor look for pattern watch out for pitfalls