Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
kitten smoothie
Dec 29, 2001

Anyone else going to the Android Dev Summit in MTV in a couple weeks?

Adbot
ADBOT LOVES YOU

Mezzanine
Aug 23, 2009
Anyone have experience using jQuery Mobile stuff in an Android WebView? Users on Lollipop with that new 'auto-updating' WebView are having all kinds of problems. I've got an HTML form that I'm showing in a WebView, and the page will stop scrolling or accepting any other input when the user either tries to show a JQM dialog, tap a <select> tag, or even tap a simple text input tag.

hooah
Feb 6, 2006
WTF?
I have my project stored on Google Drive and I'm using Android Studio. This is apparently a problem now when it wasn't a couple months back when I last worked on the project, since Google Drive insists on putting desktop.ini files everywhere, and AS chokes on them. Is the only solution to move the project out of my Google Drive folder?

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

hooah posted:

I have my project stored on Google Drive and I'm using Android Studio. This is apparently a problem now when it wasn't a couple months back when I last worked on the project, since Google Drive insists on putting desktop.ini files everywhere, and AS chokes on them. Is the only solution to move the project out of my Google Drive folder?

Maybe? You should definitely be using some sort of version control, and git is pretty ideal for cases where you're transferring the repo over a weird storage layer. Your filesystem is not an adequate version control solution.

Yes, you should even be using version control for piddly projects and when learning.

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

Volmarias posted:

Maybe? You should definitely be using some sort of version control, and git is pretty ideal for cases where you're transferring the repo over a weird storage layer. Your filesystem is not an adequate version control solution.

Yes, you should even be using version control for piddly projects and when learning.

So putting a git repo on Drive will work? Wouldn't it also get the desktop.ini files sprinkled in?

kitten smoothie
Dec 29, 2001

Why use git on top of Drive when you can just use a hosted git repo? It seems like storing a git repo on top of Drive is asking for janky behavior, at best.

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

Are there good, free, private hosted repo services? I haven't looked in a while.

Bognar
Aug 4, 2011

I am the queen of France
Hot Rope Guy
Bitbucket has free and private git/Hg repos.

Tunga
May 7, 2004

Grimey Drawer
GitLab is another which is supposed to be decent.

Edit: Consider also whether your project actually needs to be private.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

I just pay for the cheap Github plan (i think $7/month) for private repos. I like Github over the alternatives enough and it's convenient to have access to my repos wherever along with another place my code is backed up.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Subjunctive posted:

So putting a git repo on Drive will work? Wouldn't it also get the desktop.ini files sprinkled in?

You can basically back up a git repo into a single file, which you could place onto drive. It depends on how crappy you want your mechanism of source remotes to be.

If you can use something like github, or have a shell somewhere, that's definitely the way to go.

return0
Apr 11, 2007
Anyone got any experience using breakpad for the NDK and getting usable stacktraces out of C++ crashes, in a way that works across a lot of devices? Breakpad seems to work great for Samsung and Asus devices, but doesn't work for lots of other vendors. Interested to hear if anyone has got it or anything similar working?

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

I'm pretty sure Mozilla uses breakpad for their Firefox Android builds, and they wouldn't do it if they couldn't get stacks everywhere. You might look at their processing pipeline scripts to see if they're doing anything differently. Different vendors do gently caress around with native library loading, and Firefox uses its own ld.so, so they might be dodging some bullets that way.

Our app uses it too, I believe, but I haven't checked the details. I'll ask around.

speng31b
May 8, 2010

Looking for advice on Android testing infrastructure. Quick background, most places I've been have played pretty fast and loose with mobile TDD, paying it lipservice at best (if using it at all). Trying to get a better process set up at my new place. Last week I got our ~5 apps and 3 libraries set up on CirceCI, basically just making sure the builds don't break and we can autodeploy to beta users or Google Play, etc.

Now I'd like to add some actual proper tests to our CI setup, and I'm looking to triage. From what I've researched so far, it seems like the path of least resistance would probably be to get Espresso with JUnit4 set up and start enforcing that our devs write unit tests moving forward. Anyone else with experience building a testing/CI pipeline for mobile have some advice on what's worked well for them?

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...
Robolectric and Espresso. Robolectric is especially useful when possible, since the tests run directly on your computer via normal byte code, so they're VERY fast to compile and run.

You should mandate tests regardless. See about generating coverage numbers too.

speng31b
May 8, 2010

Yeah, I got the impression that last April-ish Espresso also started also supporting Unit tests run on a standard JVM, so is Robolectric still useful? That's one of the questions I had that my research wasn't able to quickly answer.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

speng31b posted:

Yeah, I got the impression that last April-ish Espresso also started also supporting Unit tests run on a standard JVM, so is Robolectric still useful? That's one of the questions I had that my research wasn't able to quickly answer.

I haven't heard anything about that. Let me know if you find that it does.

speng31b
May 8, 2010

Volmarias posted:

I haven't heard anything about that. Let me know if you find that it does.

Found that info in these two spots -

http://developer.android.com/training/testing/unit-testing/local-unit-tests.html
http://tools.android.com/tech-docs/unit-testing-support

Looks like on the latest AS you can just run standard Android unit tests on the JVM out of the box.

speng31b fucked around with this message at 02:49 on Nov 27, 2015

baka kaba
Jul 19, 2003

PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

You can run the basic tests in AS, they use a stubbed version of the Android code so you have to mock any calls to that. If you actually want to do anything that relies on the Android platform, you need an instrumentation test and that has to run on a device or emulator

speng31b
May 8, 2010

And with Robolectric you wouldn't have the same limitations of needing to run certain tests on an emulator or live device? It can run things on a standard JVM that you can't get with AS unit test support and Mockito?

baka kaba
Jul 19, 2003

PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

I don't know about the benefits of Robolectric specifically, but isn't Espresso entirely about UI testing? That explicitly relies on the platform, so you need an instrumentation test - that's what people were asking about, if you'd seen something where that's no longer the case

I only started using the Gradle-aware JVM testing and JUnit4 recently myself, but it's fairly new and as far as I know it can only handle 'pure' Java code - the Android jar it hooks into is completely non-functional, so it's there for your general code tests that can get away with basic mocking of any Android system calls

Also it would be nice if they'd update the developer docs all at once, there's a bunch of old testing stuff knocking around in there from when you had to use JUnit3 and extend AndroidTestCase etc :negative:

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

speng31b posted:

Found that info in these two spots -

http://developer.android.com/training/testing/unit-testing/local-unit-tests.html
http://tools.android.com/tech-docs/unit-testing-support

Looks like on the latest AS you can just run standard Android unit tests on the JVM out of the box.

That's not the same thing. This is just running JUnit tests with the Android elements replaced entirely with mocks. Robolectric provides shadow implementations of Android framework classes, which allow greater levels of interaction without explicitly choreographing the expected actions as that's been taken care of for you.

To expand on this, Espresso is a framework for your integration tests to make them run more smoothly and allows you to write them more cleanly, using the hamcrest matching style. For example, on the button with the text "dilzlord", click. Then, verify that the text with the parent with the id "R.id.dilzcontainer" and which is visible now has the text "dilz".

Volmarias fucked around with this message at 04:10 on Nov 27, 2015

speng31b
May 8, 2010

Yeah I'm probably blurring the lines between Espresso and regular Android unit tests. From reading over the docs they seem like the same thing? Is there a difference between Espresso and the JUnit 4 on AS stuff that runs on the JVM? Anyways, reading over the Robolectric info a bit more, I think the key distinction lies here -

quote:

An alternate approach to Robolectric is to use mock frameworks such as Mockito or to mock out the Android SDK. While this is a valid approach, it often yields tests that are essentially reverse implementations of the application code.

Robolectric allows a test style that is closer to black box testing, making the tests more effective for refactoring and allowing the tests to focus on the behavior of the application instead of the implementation of Android. You can still use a mocking framework along with Robolectric if you like.

^^ yeah that makes sense.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

speng31b posted:

Yeah I'm probably blurring the lines between Espresso and regular Android unit tests. From reading over the docs they seem like the same thing? Is there a difference between Espresso and the JUnit 4 on AS stuff that runs on the JVM? Anyways, reading over the Robolectric info a bit more, I think the key distinction lies here -


^^ yeah that makes sense.

Just edited my post. Look at Espresso to see what it is and isn't.

baka kaba
Jul 19, 2003

PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

speng31b posted:

Yeah I'm probably blurring the lines between Espresso and regular Android unit tests. From reading over the docs they seem like the same thing? Is there a difference between Espresso and the JUnit 4 on AS stuff that runs on the JVM?

The unit tests that run in AS can't use any Android framework code at all - the tests can't, and the code they call can't. If you're testing what's effectively generic Java, it works great - it just needs to run on the local JVM.

If your code does call Android stuff specifically, it will fail on a local test because the Android platform code is completely empty - it's just blank methods. If those calls are external to the code you're actually testing, and you can get away with some form of mocking (giving your code some dummy results to work with) then you can handle that with something like Mockito or Robolectric. That way you can still run on the local JVM, because you're still not relying on Android platform code being there

But if mocking isn't an option, and you need some access to the actual platform, you can't run that test locally - you have to run an instrumentation test on an emulator or a device, which has the real code. And with Espresso you're explicitly testing your UI through the UI framework, so it has to be the real deal - you're testing how it actually comes out and behaves on the user end of a real system, so you need that functionality to test what you're trying to test. If you get me

There's a nice page somewhere that gives an overview of the recommended testing tools and some introduction to them, including Espresso - I think it's linked from one of the testing doc pages

e- here we go
https://google.github.io/android-testing-support-library/

baka kaba fucked around with this message at 05:54 on Nov 27, 2015

EpicCareMadBitch
Dec 20, 2008
Any recommendations on books for a complete newbie to android developing? I have plenty of online resources, I would like a book to go along with my studies though.

Tunga
May 7, 2004

Grimey Drawer

oaok posted:

Any recommendations on books for a complete newbie to android developing? I have plenty of online resources, I would like a book to go along with my studies though.
Are you totally new to programming or just to Android? Do you know Java already?

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

oaok posted:

Any recommendations on books for a complete newbie to android developing? I have plenty of online resources, I would like a book to go along with my studies though.

If you have some programming experience, The Busy Coder's Guide to Android Development is quite good. The author keeps it up to date, and it covers basically everything you could want to know from build systems and UI to encrypted storage and performance tuning. We have a site license to it at work.

EpicCareMadBitch
Dec 20, 2008

Tunga posted:

Are you totally new to programming or just to Android? Do you know Java already?

I'm new to programming. I have some basic python down but that's it.


Subjunctive posted:

If you have some programming experience, The Busy Coder's Guide to Android Development is quite good. The author keeps it up to date, and it covers basically everything you could want to know from build systems and UI to encrypted storage and performance tuning. We have a site license to it at work.

This does look pretty informative and reviews I have been reading have been stellar on it. Thanks I'll bookmark this one. Doesn't seem there is a psychical copy out for the latest edition though :(

kitten smoothie
Dec 29, 2001

re testing chat:

I've found Robolectric to be more trouble than it's worth in some places. In my experience it hated finding resources when it came to build flavors, and also any update to the library often brings in a ton of breaking changes that lead to burning a day on yakshaving your tests. Also the shadow implementation doesn't necessarily jive with what's actually going on in the Android core and unlike instrumentation tests you can't test breaking changes between different API levels.

Google put together a code lab that's pretty handy in terms of illustrating architecting for testing, and doing a combination of JUnit tests and instrumentation tests (and also now Android Studio 2.0 breaks down some of the walls between these two, which is nice). Basically get all your business logic out into classes that don't implement the Android SDK, and then test those using plain old JUnit. Use DI to feed mocks into those implementations so you can control what's going on under testing.

Similarly, on the flip side, use Espresso instrumentation tests to test your views, and feed it mocks of your business logic so you can both tee up mock data to populate your views, and test interactions confirm that your UI is calling into that correctly.

https://www.code-labs.io/codelabs/android-testing/index.html?index=..%2F..%2Findex

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

oaok posted:

I'm new to programming. I have some basic python down but that's it.

You'll probably need to learn Java before you can effectively do any Android development. Android is a framework running atop the Java language, so if you don't have the fundamentals down, you're going to get surprised, confused, and upset trying to make some things work.

here's a nice thread with suggestions on learning Java, including Oracle's java tutorials. If you know someone who does development, you might want to chat with them about helping you get set up with a development environment, since that's usually one of the biggest hurdles.

kitten smoothie posted:

re testing chat:

I've found Robolectric to be more trouble than it's worth in some places. In my experience it hated finding resources when it came to build flavors, and also any update to the library often brings in a ton of breaking changes that lead to burning a day on yakshaving your tests. Also the shadow implementation doesn't necessarily jive with what's actually going on in the Android core and unlike instrumentation tests you can't test breaking changes between different API levels.

Google put together a code lab that's pretty handy in terms of illustrating architecting for testing, and doing a combination of JUnit tests and instrumentation tests (and also now Android Studio 2.0 breaks down some of the walls between these two, which is nice). Basically get all your business logic out into classes that don't implement the Android SDK, and then test those using plain old JUnit. Use DI to feed mocks into those implementations so you can control what's going on under testing.

Similarly, on the flip side, use Espresso instrumentation tests to test your views, and feed it mocks of your business logic so you can both tee up mock data to populate your views, and test interactions confirm that your UI is calling into that correctly.

https://www.code-labs.io/codelabs/android-testing/index.html?index=..%2F..%2Findex

That's really the way to do it, if you can cleanly architect your code in this way.

speng31b
May 8, 2010

kitten smoothie posted:

re testing chat:

I've found Robolectric to be more trouble than it's worth in some places. In my experience it hated finding resources when it came to build flavors, and also any update to the library often brings in a ton of breaking changes that lead to burning a day on yakshaving your tests. Also the shadow implementation doesn't necessarily jive with what's actually going on in the Android core and unlike instrumentation tests you can't test breaking changes between different API levels.

Google put together a code lab that's pretty handy in terms of illustrating architecting for testing, and doing a combination of JUnit tests and instrumentation tests (and also now Android Studio 2.0 breaks down some of the walls between these two, which is nice). Basically get all your business logic out into classes that don't implement the Android SDK, and then test those using plain old JUnit. Use DI to feed mocks into those implementations so you can control what's going on under testing.

Similarly, on the flip side, use Espresso instrumentation tests to test your views, and feed it mocks of your business logic so you can both tee up mock data to populate your views, and test interactions confirm that your UI is calling into that correctly.

https://www.code-labs.io/codelabs/android-testing/index.html?index=..%2F..%2Findex

I had just found this exact codelab and was coming back to the thread to update on it, and you beat me to it. I'm definitely going to go with the recommendations here. I'd already made the decision to move our apps going forward to MVP, with Dagger 2, etc. Yesterday before I'd found this I got an app hooked up with Robolectric and started playing around with it, and still wasn't quite seeing the need for it. Especially since the way my stuff is set up, I use a single Activity with dumb views and no Fragments - just plain old Views that are managed by Square's Mortar & Flow libs. Basically I just don't have a lot of need to call on platform stuff in my Presenter logic, and anything I do call can be easily extracted, injected, and mocked effectively within the context of the business logic there. With this style of MVP you wouldn't want to unit test your Android component classes anyhow, because they're all turned into super-dumb views that foward their events to presenters, and you don't need to unit test Android itself. Then just hook up standard instrumentation for the UI testing. Sounds good in theory, we'll see what happens in practice.

I guess I'll take this opportunity to plug Mortar & Flow as an MVP Fragment replacement architecture again. One of the nicest ways to work with Android I've found, super clean workflow. Some good stuff on that here -

https://corner.squareup.com/2014/10/advocating-against-android-fragments.html
https://realm.io/news/using-flow-mortar/

Unfortunately you have to look around a bit to get a practical example of Mortar & Flow working together with Dagger 2 in the context of a full sample app, since the info's all spread around, but it's totally worth it.

Edit - that code lab is also a really awesome general architecture example, even without the testing part. I especially like the way they organize packages as features rather than layers, with only model as its own "layer" package. I'm definitely using that idea. It would make using package protected access within vertical feature slices super nice.

speng31b fucked around with this message at 20:43 on Nov 28, 2015

kitten smoothie
Dec 29, 2001

I've been meaning to look into Mortar/Flow, or something similar, for my product at work. Fragments are such an ugly loving hack; it seems like a good idea up until you run into bugs introduced by the additional layer of lifecycle/state.

Farchanter
Jun 15, 2008
I'm having trouble using Shader.TileMode inside of a BitmapDrawable. Each new Bitmap drawn using the same Drawable is slightly and increasingly offset, and I'm at a loss to explain why. I think I'm missing something obvious, and any hhelp is deeply appreciated. It's the green guys in the middle of the screen.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
What are you trying to achieve, and why is playing with the tile mode the way to achieve that?

speng31b
May 8, 2010

^^^ What that guy said, and also post code if you want help.

Farchanter
Jun 15, 2008
Ah, I should have explained that in the first post. Although those blocks are the same size as their texture, I want the ability to make those blocks as large as I want them, with the texture tiling rather than stretching. I believe tile mode is the best way to accomplish that, but I may well be wrong.

E: I'll post code in a minute, thanks!

Farchanter
Jun 15, 2008
Okay, here we go, as promised:

code:
public void drawSprite(WallActor actor, Canvas canvas, Paint paint)
	{
		if (actorSheetProperties == null)
		{
			return;
		}
		
		Rect graphicsFriendlyBox = new Rect();
		
		actor.getBoundingBox().round(graphicsFriendlyBox);
		
		weirdMath(graphicsFriendlyBox, actor);	
		
		Bitmap subBitmap = Bitmap.createBitmap(SpritesheetMaster.getSheet("WallActor"), determineValueOne(actor),
		 determineValueTwo(), determineValueThree(actor), determineValueFour());
		
		BitmapDrawable drawable = new BitmapDrawable(SpritesheetMaster.getContext().getResources(), subBitmap);
		drawable.setTileModeXY(TileMode.REPEAT, TileMode.REPEAT);
		drawable.setBounds(graphicsFriendlyBox);
		
		drawable.draw(canvas);
	}
The four methods used in the Bitmap.createBitmap() call return 0, 0, 49, and 51, respectively. subBitmap has a height of 49 and a width of 51.

Thanks, and let me know if you have any other questions!

Farchanter fucked around with this message at 05:51 on Dec 1, 2015

Sub Par
Jul 18, 2001


Dinosaur Gum
In Android 4.4, Google introduced bluetooth sniffing capabilities on the phone. I now have a Nexus 5x running 6.0 and I don't see the Bluetooth sniffing option anymore. Is this something they removed, and if so, does anyone have a recommended way to sniff packets from a Bluetooth LE device (either when it's paired with the phone or otherwise)? I'm toying around with a fitness device and would like to see how the bluetooth pieces of it work and hopefully write my own app to control it. Thanks.

Sub Par fucked around with this message at 18:42 on Dec 2, 2015

Adbot
ADBOT LOVES YOU

speng31b
May 8, 2010

I've been writing BLE library code for Android for the past couple of months, and I'm not sure what you mean by sniffing. Was something like this built into settings? If so never seen it. Anyhow, you can get the advertisement bytes for any BLE device in range on most Android hardware running 4.3+, if that's what you mean. Download the nrf master control panel app, scan, profit.

If you're talking about writing your own BLE utility, I'd suggest you run fast in the opposite direction. I can go into more detail if you want, but for now I'll just say Android BLE support is -bad-. I'll do the whole rant if anyone's interested.

speng31b fucked around with this message at 03:10 on Dec 3, 2015

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply