|
There was what I guess is like a packet sniffer that would write the Bluetooth info to a log file that you could then open in Wireshark. I have a GPS watch that uses BLE, and I plan to pair it with my appand get lat/long data from it which I upload to a rails app via a JSON API. I don't actually have the watch in my possession yet so I have been writing the rails app and doing the UI portions of the Android app while I wait for the watch to arrive. I would love insight about how terrible this will be for me. This is mostly a project for fun/personal use, so if it sucks or takes a million years, I don't mind. I am asking about sniffing because there is no documentation from the watch manufacturer about what GATTs are implemented or how it structures data over BLE so I am expecting to have to reverse engineer the protocol some by watching how the watch interacts with the official app that the company produces. Hopefully this makes sense. This will be my first foray into BLE and non-trivial Android development.
|
#
?
Dec 3, 2015 06:53
|
|
|
|
| # ? May 26, 2024 21:05 |
|
|
speng31b posted: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. Please do.
|
|
#
?
Dec 3, 2015 15:37
|
|
|
Okay, overview of how to BLE on Android - Get the scan utility app I mentioned, it'll give you info about what GATT services & characteristics your thing supports. Figure out how you want to ID your device. Probably has a GATT service UUID that you can get from the BluetoothDevice object off either an LE scan result or a list of paired devices, depending on if it's paired or not. This will not uniquely ID -your- device, but all devices like yours (devices that support such a service). If you want to only connect to yours, you'll have to find it once, then cache its address (BluetoothDevice.getAddress) somewhere. You can reconstruct a BluetoothDevice object with only its known, valid mac address, so just persist that and keep it for as long as you only want to connect to "your" device. Ideally the first time prompt the user with the Bluetooth device name or something so you're 100% sure they're connecting to the device they want. Every time thereafter, you can directly initiate a connection to the BluetoothDevice you created using your persisted address. Now comes the fun part. The BLE GATT lifecycle. You get a BluetoothGattCallback that you initiate your connection with. It gets all GATT callbacks. This lifecycle behaves differently across OS versions and manufacturers, because of course it does. Start with BluetoothDevice.connectGatt, pass your callback as a param. Wait for onConnectionState change to be called with some params indicating you've got a successful connection. But wait, maybe you got a disconnect event instead. That can happen - occasional disconnection is a natural part of the BLE lifecycle, even before you get your first successful connect callback (on some OS versions). Failed to connect? If you're feeling lucky you could call BluetoothGatt.connect. Some OS versions require you to do this, others will naturally attempt to reconnect until you call close or disconnect. But you have no idea whether or not that's the case, so you just call connect, set a timer, and if X time elapses without another callback, fully close the GATT and start over again. Got lucky? Congratulations, you now have an active GATT connection. But it might still not know about any services, which are the entry point for doing literally anything interesting with your connection. Some OS versions and manufacturer stacks seem to require service discovery implicitly as part of the connection process, others cache knowledge of services from previous connections, but that's all arbitrary and you can't rely on it. So what do you do? You see if you can get your services. They may be null. If they're null, you call discoverServices, and wait for the callback on your listener. But be sure to check the params on the callback - if it fails, you can't get the services! When/if service discovery succeeds, get your services, find the one you want based on its UUID. But be sure not to try to discover services directly after a failed service discovery - or many Android devices (seems biased towards Samsungy) will get into a fail loop of discover -> fail -> discover -> fail and so on. If that happens, probably better detect it somehow and close the GATT, start over, rather than trying to discover again. Congratulations, you got your services, now you can get their characteristics, which are things you can use to read actual data (!!!). So go on, read something on that characteristic. But be careful, because... Oh, did I forget to mention? All GATT operations are asynchronous, and only one of them can be queued at a time. That's one operation per connection, period - read, write, service discovery, connect, disconnect, whatever. Was that documented anywhere? Stack overflow maybe. Either way, that queue isn't exposed to you as a developer, so you'd better roll your own queue, and be sure not to call any operations on the BluetoothGatt until the previous operation completed with a result on your callback. On the other hand, occasionally GATT eats your operation requests, so you'll just be stuck waiting forever on a result - so every operation must be both queued and initialized alongside a timeout task that, if reached, should probably just close your GATT connection and start over again, because if you get into a bad state there's not much use trying to dig out. Android doesn't expose enough information about what went wrong that you could, even if you wanted to - and the recovery process would probably be slower than just killing the GATT and reconnecting anyhow. If you want to do anything more than simple reads it's worse, because to start a notify cycle, you have to write to a descriptor to tell it to turn on notifications, then wait for onCharacteristicChanged callbacks. The descriptor write, general writes, and your standard reads are all in the same invisible queue, so you need to make sure not to overlap any operations, handle your own timeouts in case the GATT eats your requests, etc. In summary, write a big ugly operation queue + state machine with timeouts and aborts for everything. At any given point in time, be sure to write the ugliest most defensive code you can possibly imagine, then go back and make it uglier and more defensive because you're not quite there yet. And don't forget about threading - and by that I mean don't forget that LE scan callbacks get tossed back at you on arbitrary threads, and for that matter, you can't really make any assumptions about the thread on which any of these BLE callbacks are coming back at you from. So you'd better have a thread with a Looper on it ready to post all your logic back to, because that's the easiest way to avoid concurrency hell. Some GATT operations silently fail if called off the UI thread (only on some devices and OS versions). Some of them don't fail, but return you a corrupted connection that triggers your callbacks with a bunch of completely undocumented error codes. Probably in your best interest to just post all your logic back to the UI thread, which is unfortunate but safe. Sometimes using GATT will corrupt your Bluetooth state so completely that you don't have any choice but to cycle the Bluetooth adapter's power off and on again, literally, like flicker back and forth in your notification tray style. It's ugly and pisses off users, but it's better than leaking a corrupted Bluetooth state into the device (which you can do - breaking ALL Bluetooth functionality for all other apps until the adapter is power cycled either manually or programmatically). I've found some people reporting that the Bluetooth adapter can actually be corrupted so completely by GATT usage that only rebooting the device fixes it, but I haven't run into this personally. Probably just a matter of time. Still want to make a BLE utility app? speng31b fucked around with this message at 17:07 on Dec 3, 2015 |
|
#
?
Dec 3, 2015 16:54
|
|
|
speng31b posted:Oh, did I forget to mention? All GATT operations are asynchronous, and only one of them can be queued at a time. That's one operation per connection, period - read, write, service discovery, connect, disconnect, whatever. Was that documented anywhere? Stack overflow maybe. Either way, that queue isn't exposed to you as a developer, so you'd better roll your own queue, and be sure not to call any operations on the BluetoothGatt until the previous operation completed with a result on your callback. On the other hand, occasionally GATT eats your operation requests, so you'll just be stuck waiting forever on a result - so every operation must be both queued and initialized alongside a timeout task that, if reached, should probably just close your GATT connection and start over again, because if you get into a bad state there's not much use trying to dig out.
|
|
#
?
Dec 3, 2015 17:08
|
|
|
haha my god well I am certainly glad this is not my day job and I guess this explains why the official app for the watch has one star on the Play Store with hundreds of complaints. Thanks for taking the time to write all that out, I am sure it will be helpful when I start. Heading over to download that nrf app now.
|
|
#
?
Dec 3, 2015 17:27
|
|
|
speng31b posted:Still want to make a BLE utility app? Jesus. Is that clusterfuck only for BLE or is for regular BT as well?
|
|
#
?
Dec 3, 2015 17:36
|
|
|
HardDisk posted:Jesus. Only BLE, regular BT is quite stable, relatively speaking. BLE's only been in since 4.3, and is only supported by a subset of 4.3+ devices, so I don't think it's been prioritized much.
|
|
#
?
Dec 3, 2015 17:40
|
|
|
*Flashes back to Android 2.x VideoView pain* Good stuff. By which I mean, that totally sucks, and sounds like typical Android. Sorry man.
|
|
#
?
Dec 3, 2015 17:59
|
|
|
It is the definitely Androidest thing.
|
|
#
?
Dec 3, 2015 19:50
|
|
|
...and I guess that's as good a segue as any. If anyone in the DFW area wants a front-row seat to all that BLE fun and more, be sure to check out my job listing in the parent forum: http://forums.somethingawful.com/showthread.php?threadid=3075135&pagenumber=86#post453520940 Being an Android developer is neat. PM me if you want an Android dev job in Dallas.
|
|
#
?
Dec 6, 2015 05:29
|
|
|
Does anyone have experience with custom SEAndroid rules? I'd like to explore some sandboxing possibilities. (Also, as inspired by speng31b, I have a job posting for mobile security stuff in the thread.)
|
|
#
?
Dec 10, 2015 19:37
|
|
|
http://verybadalloc.com/android/2015/12/19/special-place-for-samsung-in-android-hell/ Ah, Samsung. Such a familiar feeling of disappointment.
|
|
#
?
Dec 20, 2015 09:25
|
|
|
Doctor w-rw-rw- posted:http://verybadalloc.com/android/2015/12/19/special-place-for-samsung-in-android-hell/ Yeah, had to deal with this one on the last piece of major client work I did at my last job. Whoever has to maintain that thing's going to have fun with our ProGuard rules - the Google bugreport thread hadn't quite come to a clean consensus for a solution at the time, so the rules we came up with to fix it definitely weren't so concise. Can't believe it's actually gotten worse since then. Not even the most egregious Samsung bug we found on that project. I recall my Action Bar management code had a few helpers named things like "isSamsung41x()" that would just branch and not try to do nice things like use custom typefaces in the action bar, because Samsung. speng31b fucked around with this message at 17:33 on Dec 20, 2015 |
|
#
?
Dec 20, 2015 17:29
|
|
|
The mess of LeakCanary exceptions for Samsung garbage is also impressive, just ctrl-f + Samsung and weep. Specifically, check out where they've modified AOSP code and added static Context fields. How could that possibly go wrong? There's also this crash with RxJava that we only saw on some tiny subset of Samsung devices and we could never repro it in-house with the same phones. All we could think of was it was maybe one specific carrier build that got screwed up, or they aborted an OTA. We recently decided to go to minSdkVersion 19 with our next release since the userbase below that is practically insignificant, so at least that's a few more bad Android neighborhoods I can avoid. It's nice when your customer base is one that generally upgrades their phones every two years, the downside is that they upgrade to the next Samsung. kitten smoothie fucked around with this message at 19:34 on Dec 20, 2015 |
|
#
?
Dec 20, 2015 19:25
|
|
|
Yeah the Samsung memleaks are well known. That rx crash is super weird though. At least rxjava fixed it in 1.0.16. Gotta keep an eye on that thread and see if anyone ever figures out what Samsung did to screw up the reflection access to those fields. Although to be fair I agree with Jake Wharton on that one - Samsung is dumb, but if rx is going to claim to support Android they're responsible for testing and fixing that stuff, even if it's not their fault. Should have been patched sooner and without any suggestions that it's "not a library problem". Noone gives a poo poo if it's a library's fault, they just don't want to be in the position of explaining to their boss/client how the 1000% spike in crashes is not THEIR fault. speng31b fucked around with this message at 20:20 on Dec 20, 2015 |
|
#
?
Dec 20, 2015 20:05
|
|
|
Facebook and CodePath are offering a free Android "bootcamp" (I don't like the term, but hey) at the Facebook Menlo Park campus. 8 weeks, 2 nights/week. $0. Students will get FB engineers as mentors, talks from FB Android developers, and probably some good snacks. http://codepath.com/androidbootcamp If you're interested, PM me with a bit of background and I'll connect you.
|
|
#
?
Jan 5, 2016 19:17
|
|
|
Relative Android newbie coming from iOS here. I'm trying to understand how to create UI components. I'm imagining something like the following: A component has control over a set of views. It has some kind of data source object as a member that it can make method calls on to populate itself with data. Alternatively, outsiders can call a method to notify the component of new data so the component can update itself. Listeners can be attached to it so that other objects can react to things that happen in the component (like the user made a selection or something like that). I get the impression that nesting fragments can be a pain in Android. What should inherit from or what kind of design pattern should I use in order to achieve the kind of thing I'm describing? Also, I might be trying to project iOS design patterns on to android in a way that won't work, so let me know if I'm doing that.
|
|
#
?
Jan 13, 2016 05:04
|
|
|
Quick update on my Android BLE rant from a bit back - I have now seen with my own eyes a case where using GATT can corrupt the device Bluetooth stack so completely that only restarting the device can fix it. So that's cool. Long story short, only loving use BLE for beacon and reading the advertisement data, don't connect to GATT because it's stupid and bad. Update complete.
|
|
#
?
Jan 21, 2016 01:30
|
|
|
fleshweasel posted:Relative Android newbie coming from iOS here. I'm trying to understand how to create UI components. I'm imagining something like the following: There's a testing CodeLab that I think speng(?) posted a while back, it's very good and introduces a model/view/presenter approach, so your presenters can handle notifying and updating the UI components and informing listeners that the view did something https://codelabs.developers.google.com/codelabs/android-testing/index.html An event bus might be useful if you have a lot of listeners reacting to a single event, there's one in Guava and standalone libraries like EventBus and Otto. There's also reactive stuff like RxJava but I don't know much about that, or iOS development, so I'm not sure what you're used to What kind of fragment nesting are you talking about? Like adding fragments to your UI, but each of them might contain its own little ecosystem of fragments?
|
|
#
?
Jan 21, 2016 13:12
|
|
|
Subjunctive posted:Facebook and CodePath are offering a free Android "bootcamp" (I don't like the term, but hey) at the Facebook Menlo Park campus. 8 weeks, 2 nights/week. $0. Students will get FB engineers as mentors, talks from FB Android developers, and probably some good snacks. drat I wish this was happening in NYC. My job is paying for me to take the Android nanodegree at Udacity. I'm learning stuff and completing projects but I have no idea how to gauge how much skill I'd need to work for someone else as a dev. I went from help desk to network/telecom at my current job and kinda lucked into this class.
|
|
#
?
Jan 21, 2016 18:11
|
|
|
rock2much posted:drat I wish this was happening in NYC. Not impossible that we'd run one out of the NYC office, I'll post if we do.
|
|
#
?
Jan 21, 2016 18:32
|
|
|
baka kaba posted:What kind of fragment nesting are you talking about? Like adding fragments to your UI, but each of them might contain its own little ecosystem of fragments? I assume they're going from the sort of perspective where in iOS a view controller basically owns a view and all the logic that glues it together, and in iOS it's a common pattern to compose multiple view controllers together into one "screen." It seems tempting to do this with Fragments but you're probably going to find yourself in a world of pain if you do so. If you're looking into MVP I would consider composing multiple presenters and separate views in one activity, as opposed to nesting fragments.
|
|
#
?
Jan 21, 2016 18:43
|
|
|
Subjunctive posted:Not impossible that we'd run one out of the NYC office, I'll post if we do. Thanks in advance!
|
|
#
?
Jan 21, 2016 18:58
|
|
|
kitten smoothie posted:I assume they're going from the sort of perspective where in iOS a view controller basically owns a view and all the logic that glues it together, and in iOS it's a common pattern to compose multiple view controllers together into one "screen." What kind of problems do you see? If you're messing with the backstack a lot that could get messy, but if you're just throwing fragments into the current layout and injecting their presenters it seems like a fairly simple way to separate functionality and reuse the same components in different screens. I'm guessing it's a lot easier on iOS but y'know, relatively 
|
|
#
?
Jan 21, 2016 19:22
|
|
|
Fragments are bad. Do the view hierarchies yourself or with one of many frameworks out there for it. Will elaborate more if needed, but really just Google that article square wrote on their engineering blog on why fragments are bad. That hasn't changed.
|
|
#
?
Jan 21, 2016 20:03
|
|
|
I've mainly run into lifecycle/state related issues, and those just get even worse once you start getting into nested fragments. The aforementioned Square blog post is pretty good. I've bumped into weird bugs that are all attributable to the things they point out here.
|
|
#
?
Jan 21, 2016 20:33
|
|
|
Thanks for the advice. I will check out the article from code lab. I did read square's anti fragments article which I found interesting. I have a navigation drawer which presents fragments for each item in the drawer. Should I do some kind of... reinflate and replace the content view on the activity level thing instead? I have found so far that the fragment lifecycle is pretty lovely and passing dependencies from an activity to a fragment is a bit of a pain in the rear end. Restoring state also seems pretty cumbersome. I am spoiled by iOS preserving the state of views for a relatively long time. The context is: I have a fragment containing a view which is split in half. A map on the top and a table on the bottom. The table changes data when you interact with the map and the map can show different things when you interact with the table. I want to have probably a presenter for the map as well as a presenter for the table to keep the interaction logic loosely coupled. I thought before that maybe the way to do this was nested fragments, but it just sounds bad compared to using presenters. I would like to set the map to show the user's location on load. Do I need to asynchronously get a GoogleMap and a GoogleApiClient and then provide both to the map presenter so it can handle setting the map location to the user's location?
|
|
#
?
Jan 22, 2016 09:57
|
|
|
fleshweasel posted:I would like to set the map to show the user's location on load. Do I need to asynchronously get a GoogleMap and a GoogleApiClient and then provide both to the map presenter so it can handle setting the map location to the user's location? If I were to design this I wouldn't want my presenter to know what a GoogleMap or a GoogleApiClient is, I'd just firewall it off with interfaces and some thin wrappers. I would probably create a custom view class to embody the whole map view and have it implement some kind of MyCustomMapView interface, have the presenter know about that, and all of the things that would affect the GoogleMap or map view would be done by calling MyCustomMapView interface methods. Similarly same thing with the GoogleApiClient, maybe a thin wrapper around that and again have it implement some MyApiClient interface. It sounds like a little bit extra work but by having the presenter not know directly what those are, now you can mock out those dependencies in tests (since you can use mocks to mock "an instance of some arbitrary class that implements an interface"). Then you can confirm, through tests, your presenter's business logic like "we should request a location from the API client, and when we receive it, we should update the map accordingly." The best part is this that by keeping the Google/Android frameworks from poisoning your presenter, your tests can be pure JVM tests and you'll love this because instrumentation tests on a device/emulator take like 10x longer to run. kitten smoothie fucked around with this message at 16:53 on Jan 22, 2016 |
|
#
?
Jan 22, 2016 16:50
|
|
|
kitten smoothie posted:I've mainly run into lifecycle/state related issues, and those just get even worse once you start getting into nested fragments. Hmminteresting How well does rolling your own handle activity destruction on rotation etc? I see they're talking about Mortar to handle maintaining your own state... the nice thing about fragments is you can use setRetainInstance and have whatever's in it survive the activity necromancy, and it's a fairly low-effort way to get it done. Are fragments always a no-no, even for fairly basic things? I like best practices but sometimes it feels like you have to re-do everything, you know? Thanks Android!
|
|
#
?
Jan 22, 2016 17:18
|
|
|
baka kaba posted:Hmminteresting Use Fragments for Google maps if you're forced to by your use case, nothing else. Mortar has some built in stuff for equivalency to setRetainInstance, as do all Fragment replacement solutions built on top of Views that I've seen, and it's fairly trivial to do that yourself in a way that's better and less likely to get you in trouble than what Fragments do (i.e., on Activity restore having zombie Fragments resurrected inside the Fragment Manager's internal Fragment list loving up all your poo poo). At my last job before I realized Mortar/Flow existed, I built a "Screen" abstraction to replace Fragment that did all that stuff, worked a lot better than Fragments, and it took just a couple days. Dropped it into one of our more popular apps and immediately saw the number of bullshit completely untraceable crashes fall off. Views and Activities have all the stuff you need built in since day one, and not only that, raw Views are actually really fast and very robust. Fragments are a failed experiment that have been taken too far to turn back on now. Don't use them.
|
|
#
?
Jan 22, 2016 17:54
|
|
|
I read the square article and it gave me pause that for instance their listview subclass called getActivity, casted it to their custom Activity type and called a method on it. Isn't this an undesirable degree of coupling?
|
|
#
?
Jan 22, 2016 20:10
|
|
|
fleshweasel posted:I read the square article and it gave me pause that for instance their listview subclass called getActivity, casted it to their custom Activity type and called a method on it. Isn't this an undesirable degree of coupling? This is sort of par for the course with Fragments. There may be better ways to do it, but generally for the purposes of a short code snippet that needs to easily convey "I am communicating back with my Activity and doing this thing", that's going to be more understandable than posting to an event bus or local broadcast or using an interface or whatever you might do in a real use case. Also people do use this pattern pretty frequently with Fragments.
|
|
#
?
Jan 22, 2016 20:14
|
|
|
You can see the same pattern in Google's documentation for communicating between activities/fragments except that they define the methods on an interface and have the Activity implement it. But there's still an explicit cast of the Activity.
|
|
#
?
Jan 22, 2016 20:53
|
|
|
Is there something like this article except for Android development? I haven't touched Android dev in probably 4 years, so I'm probably horribly out of date...
|
|
#
?
Jan 22, 2016 20:59
|
|
|
I haven't tried it but Lyft also open sourced a library for doing some of your fragment-ish things (backstack, etc) without fragments. https://github.com/lyft/scoop
|
|
#
?
Jan 22, 2016 21:19
|
|
|
Thermopyle posted:Is there something like this article except for Android development? I wish. One of the problems with it is how much misinformation there is floating around, even in Google's own docs and examples. Your best bet might actually just be to glance through the approaches Google uses in its sample repos - https://github.com/googlesamples?tab=repositories They actually document Android a lot better in code than plain English.
|
|
#
?
Jan 24, 2016 07:35
|
|
|
speng31b posted:Use Fragments for Google maps if you're forced to by your use case, nothing else. Mortar has some built in stuff for equivalency to setRetainInstance, as do all Fragment replacement solutions built on top of Views that I've seen, and it's fairly trivial to do that yourself in a way that's better and less likely to get you in trouble than what Fragments do (i.e., on Activity restore having zombie Fragments resurrected inside the Fragment Manager's internal Fragment list loving up all your poo poo). At my last job before I realized Mortar/Flow existed, I built a "Screen" abstraction to replace Fragment that did all that stuff, worked a lot better than Fragments, and it took just a couple days. Dropped it into one of our more popular apps and immediately saw the number of bullshit completely untraceable crashes fall off.  I like the realtalk in this thread though. The Android documentation really is frustrating, it's pretty... let's say organic
|
|
#
?
Jan 24, 2016 11:47
|
|
|
speng31b posted:I wish. One of the problems with it is how much misinformation there is floating around, even in Google's own docs and examples. The code labs at code-labs.io are really helpful too. The Google samples are excellent as well, and some of them illustrate other good practices (the fingerprint auth example for instance uses Dagger).
|
|
#
?
Jan 24, 2016 18:32
|
|
|
Is anyone able to tell me at a glance what platform this cross-platform (iOS, Android, Blackberry) app is built with? I'm assuming it's a phonegap / cordova thing, but it's be nice if someone who knows what's up would say so.
|
|
#
?
Jan 24, 2016 22:33
|
|
|
|
| # ? May 26, 2024 21:05 |
|
|
Newf posted:Is anyone able to tell me at a glance what platform this cross-platform (iOS, Android, Blackberry) app is built with? I'm assuming it's a phonegap / cordova thing, but it's be nice if someone who knows what's up would say so. Looks like it's just a WebView wrapper around a JQuery Mobile site, and was created using this https://www.biznessapps.com/ (at least from what I could tell running it through apktool).
|
|
#
?
Jan 24, 2016 23:43
|
|