flexypepo (17) [Avatar] Offline
#1
Section 7.1:
Clear, at least for me. Maybe some indication where the 'assets' go (library or part of each device-specific app) - see section 7.2 remarks.

Section 7.2:
1. section 7.2.1 and figure 7.5: its not quit clear (depending on Flash Builder skills), that the 2nd way of connecting projects is via button Add Project... If the hashtag #1 is meant to refer to the button, ignore this comment.

2. figure 7.7 is confusing, and I think, redundant. Its figure 7.8, which is the most important one.
Details:
⁃ file RottenTomatoesSplashScreen in package utils should not be copied, I think, because then assets are needed. This is not clear from the text and figure. See also remarks in section 7.3.
⁃ The same remark relates to StartupCompleteCommand.as in package controllers. Although, this might be easier to see from figure 7.8 - it is not mentioned in the list of package controller package.

Section 7.3:
1. figure 7.10: these hardware button does not all appear on Samsung Galaxy SII. Left button: yes, 2nd button: no, 3rd button: yes, 4th button: no. Maybe they can be configured, I don't know yet.

2. after listing 7.14: it is not clear from the text, that the app produces compile errors for all mediator files, due to absence of robotleg-library in libs. Adding the robotleg-library, fixes all problems except in ApplicationMediator, which is fixed quit easily (RottenTomatoesApplication -> RottenTomatoesAndroid). In my mind, it is then ready for configuration (section 7.3.2).

3. after listing 7.14: also file RottenTomatoesSplashScreen.mxml needed to be added in package com.unitedmindset.utils. Not clear from text, easy to fix in practice. Should this file be changed to adopt to Android only? It is a nice centralized splashscreen for all devices. Should it be part of RottenTomatoesLibrary, anyway?

4.section 7.3.2 - page 219:
⁃ id of ActionBar is changed, but then all mediator files complain about it (compile errors). I kept the same name "bottomActionBar". However, code in method _onKeyboardHandler must be changed (menuGroup -> bottomActionBar). Not clear from text why name should be changed to "menuGroup".

⁃ Should all described code additions and changes on page 219-220 be done in every mediator class? Not clear from text. If yes, is there no better way, because this is error-prone ('copy-paste' anti-pattern)? Should it only be placed in ApplicationMediator (seems more logical, but it has no method _setView) ???

⁃ detail: toggling the actionbar visiblity in method _onKeyBoardDownHandler could be simpler using the NOT-operator ("visible = !visible"). Seems overcomplicated to use the ?smilieperator.

5. end-of-section 7.3: strange behavior when app is executed (I've only updated BoxOfficeMediator and CurrentDvdMediator).
⁃ when bottom actionbar (ListBaseView) starts with visibility 'false', according to the text, it does NOT appear with the hardware Menukey.

⁃ when bottom actionbar (ListBaseView) starts with visibility 'true', it works (next/prev page). When the actionbar is made invisible with the leftmost Android hardware key (Menu), it will no re-appears always. It seems not to appear when switched to another view.

Peter
jonathan.campos (16) [Avatar] Offline
#2
Re: chapter 7 - section 7.1-7.3 remarks
Thoughts inline:

> Section 7.1:
> Clear, at least for me. Maybe some indication where
> the 'assets' go (library or part of each
> device-specific app) - see section 7.2 remarks.

Good thought.

>
> Section 7.2:
> 1. section 7.2.1 and figure 7.5: its not quit clear
> (depending on Flash Builder skills), that the 2nd way
> of connecting projects is via button Add Project...
> If the hashtag #1 is meant to refer to the button,
> ignore this comment.
>

Yup, #1 points to that. But I will make it even more obvious.

> 2. figure 7.7 is confusing, and I think, redundant.
> Its figure 7.8, which is the most important one.

I wasn't sure how many pictures may be necessary. So I just added them all. I agree it can be removed. Will do and save space.

> Details:
> ⁃ file RottenTomatoesSplashScreen in package
> utils should not be copied, I think, because then
> assets are needed. This is not clear from the text
> and figure. See also remarks in section 7.3.
> ⁃ The same remark relates to
> StartupCompleteCommand.as in package controllers.
> Although, this might be easier to see from figure 7.8
> - it is not mentioned in the list of package
> controller package.

You're right that these are meant to both be in device specific applications. But depending on other applications this may not be the case. This takes people making a decision about what is good for them.

>
> Section 7.3:
> 1. figure 7.10: these hardware button does not all
> appear on Samsung Galaxy SII. Left button: yes, 2nd
> button: no, 3rd button: yes, 4th button: no. Maybe
> they can be configured, I don't know yet.

Each Android device is a little different. This image shows the most possible and meant as just an example.

>
> 2. after listing 7.14: it is not clear from the text,
> that the app produces compile errors for all mediator
> files, due to absence of robotleg-library in libs.
> Adding the robotleg-library, fixes all problems
> except in ApplicationMediator, which is fixed quit
> easily (RottenTomatoesApplication ->
> RottenTomatoesAndroid). In my mind, it is then ready
> for configuration (section 7.3.2).

Good point to make sure to state.

>
> 3. after listing 7.14: also file
> RottenTomatoesSplashScreen.mxml needed to be added in
> package com.unitedmindset.utils. Not clear from text,
> easy to fix in practice. Should this file be changed
> to adopt to Android only? It is a nice centralized
> splashscreen for all devices. Should it be part of
> RottenTomatoesLibrary, anyway?

I wouldn't think it should be in the library. But again this is up to you.

>
> 4.section 7.3.2 - page 219:
> ⁃ id of ActionBar is changed, but then all
> mediator files complain about it (compile errors). I
> kept the same name "bottomActionBar". However, code
> in method _onKeyboardHandler must be changed
> (menuGroup -> bottomActionBar). Not clear from text
> why name should be changed to "menuGroup".

In section 7.3.2 you see that I don't rename the bottomActionBar, but instead add a second. I'm not sure what text is in the MEAP but I possibly already added some code to make it clearer. Add another ActionBar.

>
> ⁃ Should all described code additions and
> changes on page 219-220 be done in every mediator
> class? Not clear from text. If yes, is there no
> better way, because this is error-prone ('copy-paste'
> anti-pattern)? Should it only be placed in
> ApplicationMediator (seems more logical, but it has
> no method _setView) ???

Our app is fairly unique that so many screens are so similar. For this book I try not to overcomplicate it will many subclasses and other architecture niceties. So yes, some copy-paste here.

>
> ⁃ detail: toggling the actionbar visiblity in
> method _onKeyBoardDownHandler could be simpler using
> the NOT-operator ("visible = !visible"smilie. Seems
> overcomplicated to use the ?smilieperator.

Again, I was trying to just be very explicit with my code and not fancy. There are other ways to simplify the code, but I wanted everything as obvious as possible.

>
> 5. end-of-section 7.3: strange behavior when app is
> executed (I've only updated BoxOfficeMediator and
> CurrentDvdMediator).
> ⁃ when bottom actionbar (ListBaseView) starts
> with visibility 'false', according to the text, it
> does NOT appear with the hardware Menukey.

Will need to check but it maybe that you're missing the add listener for the key down event.

>
> ⁃ when bottom actionbar (ListBaseView) starts
> with visibility 'true', it works (next/prev page).
> When the actionbar is made invisible with the
> leftmost Android hardware key (Menu), it will no
> re-appears always. It seems not to appear when
> switched to another view.

Odd. I haven't been able to see this on my tests. Let me know if you find something about this.

>
> Peter