I am an amateur hobbyist who has been working on a trivia game for the past several weeks. The first version of the game works well from the user perspective, but the code is super messy and I'm writing a second version of the game from scratch. I'm also making a significant change to the way the game moves between pages, converting from view flipping to the use of fragments. Based on my research so far, I think that the new design is more in line with best practices, but I am not sure I fully understand how the arguments for and against the use of fragments apply to this game.
Design #1. The old design relied on three activity files: MainActivity served as a splash page that allowed users to select the appropriate difficulty level, GameActivity delivered both the trivia questions and the answers with the help of a ViewFlipper, and ScoreActivity reported the user's score while also making sure that highestScoreAchieved was recorded in PREFERENCES.
Design #2. The new design will rely on a single activity file with a single fragment container and four fragments. StartFragment is the splash page, QuestionFragment is the question page, AnswerFragment is the answer page, and ScoreFragment reports the final game score.
I think that the fragment-based Design #2 is more in line with best practices. The BIG NERD RANCH book on Android programming preaches A.U.F. ("Always Use Fragments") on the grounds that it is always more difficult to go back and add fragments after the fact, but there must be other arguments in favor of fragments as well.
I have researched this on StackOverflow, and most of the examples involve different situations (e.g. split views and reusable views).
Thus, my question: What are the arguments in favor of fragments as opposed to view flipping in the context of the game described above? Are there good arguments against a fragment-based design for this silly little trivia game?
Aaron
Simply put, Fragment
s are like mini Activity
s that allow you to break up your app logic into smaller organized units that do specific actions. This allows you break down your apps functionality into more focused, reusable components that can better adapt to different devices.
This is a much better alternative to having large Activity
s that do many things, which become bloated and hard to maintain, and well as difficult to make work with varying screen sizes and orientations (think landscape / tablets).
Fragment
s are recommended because they offer the flexibility and code organization up front, so as an application evolves and add supports for more device configurations and features, it will be easier to maintain and more flexible. I have written and in depth blog about using Fragment
s to support any device in any orientation, which covers the reasons Fragment
s were added along with an open sourced example project.
What are the arguments in favor of fragments as opposed to view flipping in the context of the game described above?
View flipping will require for all of your logic and memory to be used by the Activity
, even when only some of it is active at a time, while Fragment
s can be loaded at the appropriate time.
Are there good arguments against a fragment-based design for this silly little trivia game?
You could argue that Fragment
s do add some architectural overhead for something that is very simple. But, as your features and code increases, Fragment
s and good design will save you a lot of headache, and perform better. If you intend on releasing this game to the public, I suggest you use Fragment
s (where necessary).