Ongoing code check-in notification issue

[martasmith]

Hi Team,

I set up this issue to notify each other of regular code check-in. This issue does not need to be assigned to anyone, and everyone gets an email notification when there is an update. It is also an easy way to track code check-ins, in case the graders need to review. I think this is also in line with a suggestion we got , which is to schedule regular code check-ins. So when you do a push to GitHub, please make a quick note here as well.

[martasmith]

Team, I just did a new code push which contains the new activity, fragment, and supporting files for the asset collection screen.

[TomHarte]

I’m unclear exactly what the reviewer was getting at; normal behaviour in a project like this would be for each new feature to be developed on a separate branch, and then, if there were a developer hierarchy, issue a pull request once the feature was complete and ready for review; for our project I’d suggest it’s smarter if we trust each other just to test and merge back each feature upon completion.

On 11 Oct 2014, at 11:26 pm, martasmith notifications@github.com wrote:

Team, I just did a new code push which contains the new activity, fragment, and supporting files for the asset collection screen.

— Reply to this email directly or view it on GitHub.

[martasmith]

Thomas, are you suggesting to push everything we work on to the master instead of a separate branch? Because that is what I have been doing exactly. However, I never collaborated on any project on Github before, so I didn't know how it's supposed to be done. So I will just follow your lead on whatever you suggest.

[TomHarte]

Normally you'd have at least two branches, with work being carried out on feature branches. A lot of places even have automatic deployment from master. But this isn't meant to be a Git course so I think they're expecting us to keep it simple. Just keep doing what you're doing.

-----Original Message----- From: "martasmith" notifications@github.com Sent: ‎12/‎10/‎2014 00:14 To: "martasmith/HackTheHood" HackTheHood@noreply.github.com Cc: "Thomas Harte" thomas.harte@gmail.com Subject: Re: [HackTheHood] Ongoing code check-in notification issue (#16)

Thomas, are you suggesting to push everything we work on to the master instead of a separate branch? Because that is what I have been doing exactly. However, I never collaborated on any project on Github before, so I didn't know how it's supposed to be done. So I will just follow your lead on whatever you suggest. — Reply to this email directly or view it on GitHub.=

[martasmith]

Ok, will do, and thank for the info! It's good to know for future project contributions how it usually works. Simple works best for me now as I'm not that familiar with Git yet.

[ravirani]

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

[TomHarte]

It’s a side issue but I was going to ignore the issue of master/development as I’m unclear how it works in Android land. In web world it seems that master normally automatically tests and deploys itself. In iOS world deployments are a manual hassle with huge latency. Do we know what normal practice is with Android? I don’t recall whether test-driven development is something Nathan plans to address during the duration of this course but does any of us know whether it’s idiomatic to have an automatic submission from master?

If not then it’s a good question for Tony, I think.

On 12 Oct 2014, at 20:22, Ravi Rani notifications@github.com wrote:

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

— Reply to this email directly or view it on GitHub.

[TomHarte]

With the ActiveAndroid stuff I just merged directly to master myself, assuming it was uncontroversial. So that will be there now. It's good to know how these things are usually formally and most correctly done but we can discuss how formal and correct we want to be tomorrow.

[martasmith]

I just did another push to the master, my last push for the night. Added webpage collection screen and hooked it up the asset collection screen.

[ravirani]

I think I have the pitch deck activity at a good point for this sprint. Please check it out and let me know if you have any feedback.

[martasmith]

Ok, I was able to test. Ravi, it looks great! :)

[tonyconstantinides]

Hi, In normal practise every developer would work on their own branch and then merge to master after a code review. Since this is a small team having you each work off master branch is fine. Hope that helps......

On Sun, Oct 12, 2014 at 8:41 PM, Thomas Harte notifications@github.com wrote:

It’s a side issue but I was going to ignore the issue of master/development as I’m unclear how it works in Android land. In web world it seems that master normally automatically tests and deploys itself. In iOS world deployments are a manual hassle with huge latency. Do we know what normal practice is with Android? I don’t recall whether test-driven development is something Nathan plans to address during the duration of this course but does any of us know whether it’s idiomatic to have an automatic submission from master?

If not then it’s a good question for Tony, I think.

On 12 Oct 2014, at 20:22, Ravi Rani notifications@github.com wrote:

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/martasmith/HackTheHood/issues/16#issuecomment-58841014 .

[tonyconstantinides]

Yes that correct. Work in master, last people please make sure the code compiles and runs....

On Sun, Oct 12, 2014 at 8:22 PM, Ravi Rani notifications@github.com wrote:

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

— Reply to this email directly or view it on GitHub https://github.com/martasmith/HackTheHood/issues/16#issuecomment-58840026 .

[TomHarte]

I was mainly curious about whether Android development tends to follow the, ummm, automatic-test-and-deploy-anything-merged-to-master practice.

On 13 Oct 2014, at 16:47, Tony Constantinides notifications@github.com wrote:

Hi, In normal practise every developer would work on their own branch and then merge to master after a code review. Since this is a small team having you each work off master branch is fine. Hope that helps......

On Sun, Oct 12, 2014 at 8:41 PM, Thomas Harte notifications@github.com wrote:

It’s a side issue but I was going to ignore the issue of master/development as I’m unclear how it works in Android land. In web world it seems that master normally automatically tests and deploys itself. In iOS world deployments are a manual hassle with huge latency. Do we know what normal practice is with Android? I don’t recall whether test-driven development is something Nathan plans to address during the duration of this course but does any of us know whether it’s idiomatic to have an automatic submission from master?

If not then it’s a good question for Tony, I think.

On 12 Oct 2014, at 20:22, Ravi Rani notifications@github.com wrote:

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/martasmith/HackTheHood/issues/16#issuecomment-58841014 .

— Reply to this email directly or view it on GitHub.

[tonyconstantinides]

Yeah, It does not. Android development is not like Web development when their only one codebase and everyone shares. Developers usually work off a branch and merge into master for an integrated build.

On Mon, Oct 13, 2014 at 4:54 PM, Thomas Harte notifications@github.com wrote:

I was mainly curious about whether Android development tends to follow the, ummm, automatic-test-and-deploy-anything-merged-to-master practice.

On 13 Oct 2014, at 16:47, Tony Constantinides notifications@github.com wrote:

Hi, In normal practise every developer would work on their own branch and then merge to master after a code review. Since this is a small team having you each work off master branch is fine. Hope that helps......

On Sun, Oct 12, 2014 at 8:41 PM, Thomas Harte notifications@github.com

wrote:

It’s a side issue but I was going to ignore the issue of master/development as I’m unclear how it works in Android land. In web world it seems that master normally automatically tests and deploys itself. In iOS world deployments are a manual hassle with huge latency. Do we know what normal practice is with Android? I don’t recall whether test-driven development is something Nathan plans to address during the duration of this course but does any of us know whether it’s idiomatic to have an automatic submission from master?

If not then it’s a good question for Tony, I think.

On 12 Oct 2014, at 20:22, Ravi Rani notifications@github.com wrote:

Working on the branch sounds good to me. But, our project is in very early stage so checking in to the master should be fine too. I think the single thing to keep in mind is master should always be stable and the last person to touch it would be responsible for making sure thats the case.

As the project progresses, we should work on branches and then create a pull request when a reasonable amount of functionality is achieved.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/martasmith/HackTheHood/issues/16#issuecomment-58841014>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/martasmith/HackTheHood/issues/16#issuecomment-58971682 .

[TomHarte]

Back on the "ongoing code check-in notification issue":

• the Address object has been split into actual structured data;
• I realised I hadn't used correctly strings.xml localised text in my two fragments so I corrected that;
• I added an approval status field to User and an appropriate enum;
• I relaxed the data format for other URLs from an ArrayList to anything implementing List;
• I tidied up my ActiveAndroid annotations for readability; and
• I ran Android lint and corrected such issues with my sections as I thought were accurate. Again, for neatness.

[TomHarte]

Issues arising with the Parse object store that have now been resolved: • ambiguous Parse-side name of Website versus WebsitePage; • intransigence on whether a save cascades; and • lack of in-code clarity about exposed properties.

Give me a shout with any further convenience methods you'd like added to the model objects. I'm at least going to add one that allows you to submit an image and get back an ImageResource as part of the appropriate task.

[martasmith]

Looks like you resolved the error with the registration. I was able to register a user and also successfully log in. Yay! Thanks!

[TomHarte]

I think it will have been the ambiguity in table names; I can find no documentation on what 'should' happen in that situation so I'd probably taken us into the realm of undefined behaviour.

-----Original Message----- From: "martasmith" notifications@github.com Sent: ‎17/‎10/‎2014 21:23 To: "martasmith/HackTheHood" HackTheHood@noreply.github.com Cc: "Thomas Harte" thomas.harte@gmail.com Subject: Re: [HackTheHood] Ongoing code check-in notification issue (#16)

Looks like you resolved the error with the registration. I was able to register a user and also successfully log in. Yay! Thanks! — Reply to this email directly or view it on GitHub.=

[TomHarte]

Very minor, as I think we'll be replacing them with Parse's supplied UI, but: the login and signup fragments have shed their grey background, no longer allow you to hit the buttons multiple times (e.g. to try to sign up, say, three times) and show progress bars while doing their network activity.

[TomHarte]

I believe the following notable bugs to be addressed:

• immediate crash if the user attempts to enter per-page input in anything other than top-to-bottom order;
• pages sometimes not having their image resources to hand when an image is delivered, leading to a crash; and
• returning from the gallery having declined to select an image always causing a crash.

Plus things no user would ever have noticed:

• push notification success/failure was being logged the wrong way around (though occurring correctly); and
• the per-page screen would repopulate itself from Parse twice instead of once.

I've also been applying the static analyser and generally addressing such issues as it brings up as look like real problems and are speedy to resolve. So you'll see a bunch of pedantic corrections; rest assured it's the tool suite being pedantic — I'm just humouring it so as to be able to whittle down warnings, the better to find actual problems.

[TomHarte]

As I said in the earlier task, all NetworkFragments were just communicating network activity status and any network exceptions that occur to their parent activity. I've therefore updated MainNavigationActivity to show a loading spinner and to display network exceptions.

[TomHarte]

The three form fragments have been given a uniform naming convention of [Model object]Fragment and moved into their own sub-package.

If they're significantly larger than that, images are now scaled down to two megapixels for upload and the JPEG quality quantum has been reduced. Given that we're now in an age of computers with 15 megapixel displays, two megapixels for upload doesn't feel excessive.

[TomHarte]

I have:

• massively simplified the stuff about descending Parse fetching, albeit temporarily to break fetch-as-refresh, but the new interface is much less syntax and the fix will be completely local to the one new class ParseIterator, leaving everyone else in their much simplified state;
• taking advantage of that simplification, have implemented a method on User that asynchronously pre-warms the cache with all relevant User-connected objects; and
• added such pre-warming at an appropriate moment within ApplicationFragment.

The net effect should be much faster navigation as normally no network access is needed when entering a form. By virtue of that I also discovered two contractual race conditions (i.e. probably not when you factor in the event loop and reasonable assumptions but technically allowed to be depending on Google's implementation of Fragment) and fixed them.

The iterator issue currently affects 0% of our code, I think, but I'll fix it tomorrow as it will affect timed User refreshes.