Use fragments in MainActivity

[daverix]

In order to be able to create a better UI, the first step is to use fragments. This PR will make the app look like this to start with: https://photos.google.com/share/AF1QipMULPT_AQ8vHM6-kmJmzUxCyDCrQaQ89c1XThXjmImpsJGnkXZUD3tfZDgbb6rMgg?key=TTl0Z1Uxa0oteC03XzItTWREYnJvQWpwRkZ4MjRB

I hope upgrading android version target isn't a problem...

[jonasoreland]

i would love to start merging this...but I'm stuck on #317

[jonasoreland]

Hi,
Can you update this??
now that it looks like v1.49 is finally getting releasable

/Jonas

[daverix]

Done :)

[jonasoreland]

and...same question about supportfragment (manager)...
is that no longer needed for apps supporting old and new devices ??

[daverix]

When using a support fragment, it's LoaderManager is of the support library type so we still use the support fragment manager etc.

[jonasoreland]

I don't understand: "Now we still use a froyo version because of some google play things, but if we can solve that too then we only need one flavor."

1. your current PR doesn't break froyo ?

[daverix]

No it shouldn't.
On Sep 16, 2015 9:59 AM, "Jonas Oreland" notifications@github.com wrote:

I don't understand: "Now we still use a froyo version because of some
google play things, but if we can solve that too then we only need one
flavor."

1. your current PR doesn't break froyo ?

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[jonasoreland]

fyi, was about to merge this...but it had conflicts. will merge manually tonight (or as soon as i find time).

[jonasoreland]

tried merging...and found that size of APK increases a lot....specially for froyo
froyo: 1014K => 1.8M (80% increase)
latest: 3.5M => 4.1M (17% increase)

Do you know why ??

[daverix]

Probably because newer support library have more code and proguard is not
running minimize for support libs?
On Sep 17, 2015 17:32, "Jonas Oreland" notifications@github.com wrote:

tried merging...and found that size of APK increases a lot....specially
for froyo
froyo: 1014K => 1.8M (80% increase)
latest: 3.5M => 4.1M (17% increase)

Do you why ??

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[jonasoreland]

hmm...can you fix so that froyo does not increase as much ?

[daverix]

I can take a look in the weekend.
On Sep 18, 2015 12:39 AM, "Jonas Oreland" notifications@github.com wrote:

hmm...can you fix so that froyo does not increase as much ?

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[daverix]

Rebased against master, will check apk sizes now.. Is it release you checked?

[jonasoreland]

yes, I checked release...
froyo: v1.50 1014K
latest: v1.50 3.5M

On Sat, Sep 19, 2015 at 1:00 PM, David Laurell notifications@github.com
wrote:

Rebased against master, will check apk sizes now.. Is it release you
checked?

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[daverix]

I have now managed to get down the sizes to the following:

froyo debug: 2.8MB
froyo release: 1.9MB

latest debug: 4.3 MB
latest release: 3.4MB

I think the reason for the larger file sizes corresponds to all new image resources used to get the material design look and feel on devices with version lower than Android 5.0.

[jonasoreland]

hmm...froyo is almost twice as big...

i think people on older devices generally like the small footprint...
but does 2Mb vs. 1Mb matter,

wdyt ?

/Jonas

On Sat, Sep 19, 2015 at 2:34 PM, David Laurell notifications@github.com
wrote:

I have now managed to get down the sizes to the following:

froyo debug: 2.8MB
froyo release: 1.9MB

latest debug: 4.3 MB
latest release: 3.4MB

I think the reason for the larger file sizes corresponds to all new image
resources used to get the material design look and feel on devices with
version lower than Android 5.0.

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[daverix]

I don't know how many still uses old froyo phones but I don't think it
matter much if its 2mb instead of 1mb.
On Sep 19, 2015 4:24 PM, "Jonas Oreland" notifications@github.com wrote:

hmm...froyo is almost twice as big...

i think people on older devices generally like the small footprint...
but does 2Mb vs. 1Mb matter,

wdyt ?

/Jonas

On Sat, Sep 19, 2015 at 2:34 PM, David Laurell notifications@github.com
wrote:

I have now managed to get down the sizes to the following:

froyo debug: 2.8MB
froyo release: 1.9MB

latest debug: 4.3 MB
latest release: 3.4MB

I think the reason for the larger file sizes corresponds to all new image
resources used to get the material design look and feel on devices with
version lower than Android 5.0.

—
Reply to this email directly or view it on GitHub
<
https://github.com/jonasoreland/runnerup/pull/309#issuecomment-141660515>
.

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[nebmo]

Jonas, I think you have to decide if you want new looks or small app. Can't have both..

[jonasoreland]

damn in...should have made these comments prior to merge.

1. missing target annotations! (the ones causing Bug: Widget added to master doesn't work on froyo #324)
2. the account list in DetailActivity, is super small on my phone. Almost not usable
3. the notes field in DetailActivty is hard to see (it is no longer white)

Can you fix ?

[daverix]

1. I didn't cause it, but I could look at it, just not right now...
2. I will go through my changes real quick to see what caused it.
3. Does Add spacing around notes edittext to make it more visible #328 work for you?

[daverix]

2. Does Fix row height of share in details activity #329 look ok?

[jonasoreland]

1. I know you didn't cause that one.
   But your patch (that I merged) removed @TargetApi(Build.VERSION_CODES.FROYO) annotations.
   And it was missing annotations that made us not notice the build failure.
   Conclusion: We should have the annotations everywhere, then we get build failure rather
   than runtime failures.

2. I commented your other fixes individually.

/Jonas

[bagage]

1. concerning that I know it's my fault, but since I never build Froyo personally I do not see them (my fault)..and travis build seems fine with it.
   Do you know any way to detect these invalid API calls from android studio? We could change travis configuration so that it fails in that case.

[jonasoreland]

the target annotations makes build fail
if using incorrect apis...

On Wed, Sep 23, 2015 at 7:15 PM, Gautier Pelloux-Prayer <
notifications@github.com> wrote:

1. concerning that I know it's my fault, but since I never build Froyo
   personally I do not see them (my fault)..and travis build seems fine with
   it.
   Do you know any way to detect these invalid API calls from android studio?
   We could change travis configuration so that it fails in that case.

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[jonasoreland]

pingeling.

how is progress on this? many things are still missing to make this good.
maybe I should rollback and you can fix thing wo/ me harassing ?

/Jonas

On Wed, Sep 23, 2015 at 7:24 PM, Jonas Oreland runnerup.android@gmail.com
wrote:

the target annotations makes build fail
if using incorrect apis...

On Wed, Sep 23, 2015 at 7:15 PM, Gautier Pelloux-Prayer <
notifications@github.com> wrote:

1. concerning that I know it's my fault, but since I never build Froyo
   personally I do not see them (my fault)..and travis build seems fine with
   it.
   Do you know any way to detect these invalid API calls from android
   studio? We could change travis configuration so that it fails in that case.

—
Reply to this email directly or view it on GitHub
#309 (comment)
.

[jonasoreland]

reverted...see c8cc63f.