These are chat archives for scala-android/sbt-android

27th
Jan 2017
Perry
@pfn
Jan 27 2017 20:12
weee for protify fixes...
saves me so much time on my current project....
since I have to have the phone plugged into a usb device and not the pc, have to send shit over wifi, and installing a big ass application takes forever
(not to mention the existing gradle build is ass)
Gregg Hernandez
@gregghz
Jan 27 2017 20:29
when I use protify sometimes my image assets get super wonky. Occasionally the wrong image will be loaded and (worse) sometimes I get class cast errors for views. Doing android:install fixes both issues
Perry
@pfn
Jan 27 2017 20:29
not sure what the cause would be, try 1.4.1-SNAPSHOT (clone + plugin/publish-local)
Gregg Hernandez
@gregghz
Jan 27 2017 20:31
it's fine for changing scala/kotlin. But when I edit xml I get unexpected results pretty often
Perry
@pfn
Jan 27 2017 20:32
that's rarely the case for me
I edit xml all the time and it doesn't load the wrong resources
Gregg Hernandez
@gregghz
Jan 27 2017 20:32
I'll see if I can pin down more specifically what triggers it
but when it works, I absolutely love it.
Perry
@pfn
Jan 27 2017 20:34
best way to identify would be to examine the protify-resources.ap_ and the resources.arsc in the apk
you can use aapt d xmltree and aapt d resources
to make sure everything maps correctly
if there's a discrepancy, I'd like to see why/what makes it occur
and of course, ensure that your R constant matches what's in resources.arsc (aapt d resources) and the corresponding file in protify-resources.ap_
(protify-resources.ap in 1.4.1-SNAPSHOT, it's just resources-debug.ap in 1.4.0
depending on where the discrepancy exists, it's possible to detect and force a rebuild (usual solution; but perhaps this scenario isn't caught)
Gregg Hernandez
@gregghz
Jan 27 2017 20:37
i'm not sure I follow. What exactly is the process to find discrepancies?
Perry
@pfn
Jan 27 2017 20:38
check the value of the constant that is not correct in R.java
verify TR if you're using TR
then check aapt d resources that the value is the same
then check the resource file (if png, just decompress, if xml, aapt d xmltree)
the resource file would be resources-debug.ap_
you would use aapt d xmltree against the .ap_, d resources against the apk
Gregg Hernandez
@gregghz
Jan 27 2017 20:40
ok I think I understand. Next time I have weird stuff going on I'll try this
Perry
@pfn
Jan 27 2017 20:40
thanks
only time it should really fail is if you're adding new resources or deleting resources (and it's supposed to be detected when this is the case)
Gregg Hernandez
@gregghz
Jan 27 2017 20:49
I think I'm doing this wrong
~/Android/Sdk/build-tools/25.0.0/aapt d xmltree ./app/target/android/intermediates/packaging/resources-debug.ap_                     
ERROR: no dump xmltree resource file specified
Perry
@pfn
Jan 27 2017 20:49
last argument would be the path to an xml file
res/layout/somelayout.xml
Gregg Hernandez
@gregghz
Jan 27 2017 20:53
ok, looks like the ids are correct. A: android:color(0x010101a5)=@0x7f0e001c in the drawable. public static final int commentPanelBg=0x7f0e001c; in R.java, resource 0x7f0e001c com.lucidchart.android.chart:color/commentPanelBg: t=0x1d d=0xfffafafa (s=0x0008 r=0x00) in the apk. but in the app itself it's showing up as black instead of #fafafa (I just changed it from black to #fafafa)
i don't know if it matters, but this is in a fragment that is not loaded immediately with the activity
Perry
@pfn
Jan 27 2017 20:54
shouldn't matter, try 1.4.1-SNAPSHOT
Gregg Hernandez
@gregghz
Jan 27 2017 20:54
alright
Perry
@pfn
Jan 27 2017 20:55
I made a fix to load some resources earlier
so it might make a difference
scala-android/sbt-android-protify@75242fa
Gregg Hernandez
@gregghz
Jan 27 2017 21:06
very weird. so it still has the issue. I'm using sbt-android 1.7.4-SNAPSHOT and sbt-android-protify 1.4.1-SNAPSHOT. I have a drawable using a color. I started with the color as @color/lightGray, did android:install. Everything good. Changed the color to @android:color/black, did protify. Still everything good. I then changed the color back to @color/lightGray, ran protify again and it still shows as black in the app
Gregg Hernandez
@gregghz
Jan 27 2017 21:17
changing the value of <color name="lightGray">...</color> doesn't seem to matter either. I started at android:install with it set to #000000 and any changes I make to it (#fafafa and then #ffffff) didn't apply in app, it stays black after each protify
hmm, i changed it once more and this time it applied correctly
Gregg Hernandez
@gregghz
Jan 27 2017 21:23
ok, so it seems like a race condition between when the color gets uploaded/updated on device and when the app loads the resource. When I protify and the resource isn't updated in app correctly, if I restart the app, the color is correct
Perry
@pfn
Jan 27 2017 21:23
hmmm
Gregg Hernandez
@gregghz
Jan 27 2017 21:23
and sometimes it will get the color correct via only protify
Perry
@pfn
Jan 27 2017 21:23
thanks for looking
so the resources are all correct, but not getting loaded, hard to say
Gregg Hernandez
@gregghz
Jan 27 2017 21:23
yeah
Perry
@pfn
Jan 27 2017 21:24
most of the time, re-starting the app should have them all show up correctly
especially on 1.4.1-SNAPSHOT and newer
Gregg Hernandez
@gregghz
Jan 27 2017 21:24
yeah, I need to work on the loading time of our app :grimacing: that's not a fun dev cycle :D
Perry
@pfn
Jan 27 2017 21:25
yeah, my current project has a pretty crappy dev cycle as well
since the phone has to be connected to a usb device
and all the state occurs on startup, so can't even protify for any live changes
state = device initialization
Gregg Hernandez
@gregghz
Jan 27 2017 21:26
yikes, not being able to debug over usb is killer. I tried the wifi debugging stuff and ... it wasn't great.
Perry
@pfn
Jan 27 2017 21:26
wifi debugging works great
the only pain is having to do adb connect when adb is killed (starting/stopping intellij, enabling/disabling adb integration, etc.)
there's the adb-wifi command for starting up adb over wifi and initially connecting to the device
Gregg Hernandez
@gregghz
Jan 27 2017 21:27
heh, maybe. I spent maybe 20 minutes using wifi because I thought it would be nice to not have the cable. Deploys to the device failed about 1/3 of the time
likely network issues
Perry
@pfn
Jan 27 2017 21:27
yeah, I haven't had problems deploying, but it's a little slower than usb
sending 30mb of apk over
and ~15mb of resources when not doing full apk
Perry
@pfn
Jan 27 2017 23:16
@gregghz, oh yeah, what device are you running on? perhaps there's a version mismatch
(i.e. maybe some steps are missing for a particular android version)
Gregg Hernandez
@gregghz
Jan 27 2017 23:17
I've been using a nexus 7 with android 6.0.1 today
I've had similar issues on a one plus 3 with android 7 though I think
Perry
@pfn
Jan 27 2017 23:17
no one is interested in developing roms heremore
oops
stupid mac
I don't have a 6.x device to verify anymore
but the app I'm currently working on requires me to restart the activity to show changes anyway (second-screen application)
Gregg Hernandez
@gregghz
Jan 27 2017 23:18
let me try the op3 some more and see. I'm pretty sure it had similar issues though
Gregg Hernandez
@gregghz
Jan 27 2017 23:48
pretty much the same on android 7
pfn @pfn shrugs
Perry
@pfn
Jan 27 2017 23:49
hard to say
I guess some context has an out-of-date Resources somewhere
if I ever repro it consistently, it's something I can look into
Gregg Hernandez
@gregghz
Jan 27 2017 23:50
sounds good. maybe one day I'll see if I can create a minimal project that exhibits the behavior. Not today though :)