|
Anyone else going to the Android Dev Summit in MTV in a couple weeks?
|
# ? Nov 1, 2015 19:23 |
|
|
# ? May 30, 2024 13:22 |
|
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.
|
# ? Nov 7, 2015 07:51 |
|
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?
|
# ? Nov 11, 2015 15:46 |
|
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.
|
# ? Nov 11, 2015 15:53 |
|
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. So putting a git repo on Drive will work? Wouldn't it also get the desktop.ini files sprinkled in?
|
# ? Nov 11, 2015 16:14 |
|
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.
|
# ? Nov 11, 2015 16:26 |
|
Are there good, free, private hosted repo services? I haven't looked in a while.
|
# ? Nov 11, 2015 16:28 |
|
Bitbucket has free and private git/Hg repos.
|
# ? Nov 11, 2015 16:40 |
|
GitLab is another which is supposed to be decent. Edit: Consider also whether your project actually needs to be private.
|
# ? Nov 11, 2015 17:17 |
|
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.
|
# ? Nov 11, 2015 17:34 |
|
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.
|
# ? Nov 11, 2015 17:35 |
|
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?
|
# ? Nov 19, 2015 22:41 |
|
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.
|
# ? Nov 20, 2015 04:02 |
|
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?
|
# ? Nov 27, 2015 02:16 |
|
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.
|
# ? Nov 27, 2015 02:30 |
|
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.
|
# ? Nov 27, 2015 02:34 |
|
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.
|
# ? Nov 27, 2015 02:39 |
|
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 |
# ? Nov 27, 2015 02:43 |
|
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
|
# ? Nov 27, 2015 02:58 |
|
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?
|
# ? Nov 27, 2015 03:01 |
|
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
|
# ? Nov 27, 2015 03:33 |
|
speng31b posted:Found that info in these two spots - 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 |
# ? Nov 27, 2015 04:06 |
|
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. ^^ yeah that makes sense.
|
# ? Nov 27, 2015 04:09 |
|
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 - Just edited my post. Look at Espresso to see what it is and isn't.
|
# ? Nov 27, 2015 04:10 |
|
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 |
# ? Nov 27, 2015 05:48 |
|
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.
|
# ? Nov 27, 2015 13:45 |
|
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.
|
# ? Nov 27, 2015 14:41 |
|
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.
|
# ? Nov 27, 2015 15:39 |
|
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
|
# ? Nov 27, 2015 16:13 |
|
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
|
# ? Nov 27, 2015 19:36 |
|
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: That's really the way to do it, if you can cleanly architect your code in this way.
|
# ? Nov 28, 2015 01:24 |
|
kitten smoothie posted:re testing chat: 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 |
# ? Nov 28, 2015 16:06 |
|
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.
|
# ? Nov 29, 2015 04:36 |
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.
|
|
# ? Dec 1, 2015 02:48 |
|
What are you trying to achieve, and why is playing with the tile mode the way to achieve that?
|
# ? Dec 1, 2015 03:35 |
|
^^^ What that guy said, and also post code if you want help.
|
# ? Dec 1, 2015 03:48 |
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!
|
|
# ? Dec 1, 2015 03:49 |
Okay, here we go, as promised:code:
Thanks, and let me know if you have any other questions! Farchanter fucked around with this message at 05:51 on Dec 1, 2015 |
|
# ? Dec 1, 2015 05:48 |
|
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 |
# ? Dec 2, 2015 18:38 |
|
|
# ? May 30, 2024 13:22 |
|
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 |
# ? Dec 3, 2015 03:06 |