|
Doh004 posted:Gotcha, that's more related to app support which is good to know - I'm actually asking about the business development people? Who manages the Play Store categories? How do you get featured more prominently? Set up partnerships between the two etc. I do not know the answer to your questions, but I do know Google. I would bet that its almost all algorithmic.
|
# ? Jun 22, 2017 16:28 |
|
|
# ? May 15, 2024 17:15 |
|
Doh004 posted:Gotcha, that's more related to app support which is good to know - I'm actually asking about the business development people? Who manages the Play Store categories? How do you get featured more prominently? Set up partnerships between the two etc. I'm not an expert or anything but I'm not sure that's really a thing? You have the usual app store optimization tips you can study , using keywords etc... Or spend a bunch of money on marketing I suppose.
|
# ? Jun 22, 2017 17:23 |
|
Thermopyle posted:I do not know the answer to your questions, but I do know Google. I would bet that its almost all algorithmic. John F Bennett posted:I'm not an expert or anything but I'm not sure that's really a thing? You have the usual app store optimization tips you can study , using keywords etc... That's what we figured! We're much more established on the App Store, so trying to break into the Play Store has been an interesting learning experience. Thanks for the responses
|
# ? Jun 23, 2017 16:52 |
|
The best way to get featured is to be a known brand and then wait for Google to approach you about some new tech they have in the works. My company was asked if we wanted to be part of the Android Pay launch in the UK, for example, but we were tied up with other things and didn't think it would be that big so business people declined. I realise that "be a known brand" is not a thing you can just do.
|
# ? Jun 24, 2017 13:24 |
|
Tunga posted:The best way to get featured is to be a known brand and then wait for Google to approach you about some new tech they have in the works. My company was asked if we wanted to be part of the Android Pay launch in the UK, for example, but we were tied up with other things and didn't think it would be that big so business people declined. We were hoping to avoid the wait! We are a known brand and one of the few mealkit companies on Google Play. I'll just relay to folks even more patience
|
# ? Jun 26, 2017 15:00 |
|
If you're paying for any other sort of Google services and have an account manager person at Google to contact over it, like GSuite, GCP, etc, I might at least try going to them and seeing if you can't get an introduction to a Play bizdev person that way. Otherwise afaict it's "don't call us, we'll call you."
|
# ? Jun 26, 2017 15:34 |
|
I'm trying to verify that my app is receiving UDP traffic from port 12001 to rule out the app being broken and see if the device sending the UDP signals (a vehicle) is actually sending them. What's the best way to do this? there seems to be a lot of sniffers on the play store but they seem to require connection to a VPN and they seem to be dodgy. I need a solution that doesnt require a rooted device as well
|
# ? Jul 11, 2017 19:06 |
|
FAT32 SHAMER posted:I'm trying to verify that my app is receiving UDP traffic from port 12001 to rule out the app being broken and see if the device sending the UDP signals (a vehicle) is actually sending them. What's the best way to do this? there seems to be a lot of sniffers on the play store but they seem to require connection to a VPN and they seem to be dodgy. these are two separate problems, you can test UDP receiving by sending data with for example netcat if you're in the same network pre:$ echo asd|nc -u <phone-ip> 12001 https://developer.android.com/training/monitoring-device-state/doze-standby.html also UDP seems like an awful idea in 2017, but maybe you don't have a choice?
|
# ? Jul 11, 2017 19:30 |
|
Vesi posted:these are two separate problems, you can test UDP receiving by sending data with for example netcat if you're in the same network it's for vehicle to vehicle communications so you can imagine what i'm dealing with
|
# ? Jul 11, 2017 19:31 |
|
Vesi posted:these are two separate problems, you can test UDP receiving by sending data with for example netcat if you're in the same network For a mobile device where the time the radio is on is directly correlated to battery life, why is UDP bad? I’ve personally had to do a lot of work around batching up network traffic to give double digit battery gains and if I could have used UDP for it, I would have in a heart beat.
|
# ? Jul 11, 2017 20:19 |
|
I asked the big brains and the reason for using UDP is so vehicles can communicate their location quicker without worrying about a response packet and can get away with missing information.
|
# ? Jul 11, 2017 20:21 |
|
Hughlander posted:For a mobile device where the time the radio is on is directly correlated to battery life, why is UDP bad? I’ve personally had to do a lot of work around batching up network traffic to give double digit battery gains and if I could have used UDP for it, I would have in a heart beat. UDP handles firewalls/NAT very inconsistently, and if you want to do anything serious with it you'll probably re-invent the TCP wheel badly. With TCP you already have full control over how often you send the connection keepalive packets (if you control the server that is) so there shouldn't be any battery saving either. UDP is great for: * If your bandwidth is so tiny you can't handle the ~40 bytes in response packets * If your data is literally garbage and can afford to throw it into a black hole without ever knowing what happens to it * DNS Vesi fucked around with this message at 21:31 on Jul 11, 2017 |
# ? Jul 11, 2017 21:28 |
|
Vesi posted:UDP handles firewalls/NAT very inconsistently This is especially bad, because lots of mobile networks are using carrier NAT now.
|
# ? Jul 12, 2017 05:00 |
|
Vesi posted:UDP handles firewalls/NAT very inconsistently, and if you want to do anything serious with it you'll probably re-invent the TCP wheel badly. With TCP you already have full control over how often you send the connection keepalive packets (if you control the server that is) so there shouldn't be any battery saving either. ... Places where you want to transparently handle IP address changes. (Wifi to cell, to different wifi) Places where you only care about the most recent set of data and don’t need to block on a dropped radio packet Places where you’re already talking to a known and fixed address and never need to NAT negotiate As in, in the case that I used it action games.
|
# ? Jul 12, 2017 05:31 |
|
Is there a kotlin thread? Is this the kotlin thread?
|
# ? Jul 12, 2017 15:44 |
|
Sereri posted:Is there a kotlin thread? Is this the kotlin thread? This is the kotlin thread!
|
# ? Jul 12, 2017 15:47 |
|
Mostly an observation (and possibly borderline racist): My Chinese coworker has stereotypical problems with r and l sounding similar. val / var seems to be unnecessarily asking for trouble as you could have named one of them basically anything else.
|
# ? Jul 12, 2017 16:00 |
|
Do most language designers even think about non-(native) English speakers? I don't think that's racist though, 'l' and 'r' (especially the English 'r') don't really exist as separate sounds in a lot of languages, so some people never learn to hear or produce them both easily Of course var has no 'r' sound as god intended
|
# ? Jul 12, 2017 17:51 |
|
Ask your coworker what the phonetic pronunciations of Value and Variable are in their native tongue, use shortened values of that.
|
# ? Jul 12, 2017 17:57 |
|
The "a" phoneme is different between "var" and "val". Also how often are you dictating code to each other?
|
# ? Jul 13, 2017 09:05 |
|
Ok boyos who wants so Stack Exchange e-points https://stackoverflow.com/questions/45090837/nullpointerexception-on-asynctask-execute dont let EE's write loving android apps
|
# ? Jul 13, 2017 22:14 |
|
I can't see which is line 61 of MainActivity (where you're calling a method on a null object) but I'm guessing you're meant to be assigning to an mListeningService field in onCreate instead of creating a local variable?
|
# ? Jul 13, 2017 22:34 |
|
baka kaba posted:I can't see which is line 61 of MainActivity (where you're calling a method on a null object) but I'm guessing you're meant to be assigning to an mListeningService field in onCreate instead of creating a local variable? Yeah I marked it here. The EE created the mAndroidUDP.startIt() method which looks like this Java code:
Here's the onCreate method Java code:
|
# ? Jul 13, 2017 22:46 |
|
Where's listeningService getting assigned in AndroidUDP?
|
# ? Jul 13, 2017 23:04 |
|
baka kaba posted:Where's listeningService getting assigned in AndroidUDP? Java code:
They havent had real programmers in the company until like March and now that we have some down time theyre coming to us to fix their broken code that's due tomorrow at 3p pls can u make this work!!! My existence is pain FAT32 SHAMER fucked around with this message at 23:26 on Jul 13, 2017 |
# ? Jul 13, 2017 23:23 |
|
I haven't done a lot with services and there's a bunch of weird stuff in there (what's listeningService.intent1, I don't see that field? What's with creating a ListeningService with new?) that should stop it running at all, I'm guessing you're trying to cut out code so it's not all over the internets but it's hard to look through You could try this Java code:
The binding stuff... it's referring to intent1 which isn't initialised anywhere, and maybe that's the mysterious listeningService.intent1 and... yeah this is hard to follow. It's hard to know if this will break anything, you can always try it Otherwise get your debugger open, stick a watch on that listeningService variable that's going null and see what's doing it
|
# ? Jul 14, 2017 00:30 |
|
You're sending imminent forward collision alerts via UDP?
|
# ? Jul 14, 2017 00:38 |
|
b0lt posted:You're sending imminent forward collision alerts via UDP? That's exactly what I said baka kaba posted:I haven't done a lot with services and there's a bunch of weird stuff in there (what's listeningService.intent1, I don't see that field? What's with creating a ListeningService with new?) that should stop it running at all, I'm guessing you're trying to cut out code so it's not all over the internets but it's hard to look through Thanks for this, I'll see how it goes tomorrow when I get in
|
# ? Jul 14, 2017 02:16 |
|
I decided to say gently caress it and instead of trying to use the listener as a service, just use an AsyncTask as an inner class of the main activity because it's a single activity app and there's no reason to overcomplicate it like the original guy did. Stupid question time: in the onPostExecution I understand that this would be where I set the text/image of my TextView and ImageView. According to this stackoverflow question quote:If this is an inner class of your Activity then initialize the View in the Activity then update it in your task as described above.
|
# ? Jul 14, 2017 22:43 |
|
They're saying hold the reference in the activity class, initialise it with findViewById when the activity is setting up (like in onCreateView) and then just refer to that from your AsyncTask
|
# ? Jul 14, 2017 23:11 |
|
baka kaba posted:They're saying hold the reference in the activity class, initialise it with findViewById when the activity is setting up (like in onCreateView) and then just refer to that from your AsyncTask If I reference it from onCreate that causes a static/nonstatic error, wouldn't it?
|
# ? Jul 14, 2017 23:26 |
|
Nah you have a non-static TextView field or whatever in your activity, assign it when you can grab a reference to the actual View after it's been inflated. onCreateView is the best time to do this - inflate your layout, do your findViewById stuff to pluck out the Views you want references to, then return the inflated layout view as usual Then with your AsyncTask as an inner class of the activity it can access that reference. Just make sure it doesn't try to access it before you've actually set it - so start your task after the view field is assigned (You can't grab the view in onCreate because you haven't inflated your layout yet)
|
# ? Jul 14, 2017 23:40 |
|
baka kaba posted:Nah you have a non-static TextView field or whatever in your activity, assign it when you can grab a reference to the actual View after it's been inflated. onCreateView is the best time to do this - inflate your layout, do your findViewById stuff to pluck out the Views you want references to, then return the inflated layout view as usual Ahhh that explains a lot. I always forget about the difference between the two
|
# ? Jul 15, 2017 05:01 |
|
So I successfully got my AsyncTask working and it receives the data that is pinged to it and changes the ImageView and TextView based on what the message says when parsed. It works almost exactly how I'd like it to except for one problem: you have to press the button multiple times, which means if the packet data changes, you have to be clicking it quite frequently to get the update. I attempted to use a ToggleButton with a while loop to continuously run the AsyncTask while the ToggleButton had .isChecked = true, however as you can imagine this caused it to crash due to what I assume was too much data on the UI thread. So based on this, I believe that I need to rewrite this as a service so that it can run on its own thread and not kill everything. This is what my AsyncTask currently looks like: Java code:
edit: I guess this would work? https://gist.github.com/finnjohnsen/3654994 FAT32 SHAMER fucked around with this message at 17:15 on Jul 18, 2017 |
# ? Jul 18, 2017 17:04 |
|
Without looking at or caring about any of your code, I'd like to point out that you can start a new thread from an Activity, it doesn't actually need to live in a service unless you'd like it to persist when the Activity goes away for some reason. Create a static class that implements Runnable. Have it's run method check for some member value like isRunning (give it the volatile keyword) and return when false. Have a method that sets isRunning to false, call it in onPause. Pass a Handler reference to your constructor, and pass messages to the handler when you need to update the UI. Create an instance and start a new thread with it in onResume (keep a reference to it so that you can end it in onPause) Your Handler will update on the UI thread when it receives a message, so update your text fields with whatever. Refactoring this to be fault tolerant is left as an exercise to the reader.
|
# ? Jul 18, 2017 19:14 |
|
Yeah if you're rewriting it I'd ditch the AsyncTask which is really meant as a quick way to do something off the UI thread and deliver the result on it. I don't really know much about UDP or preventing car accidents, but it feels like you might want something running in its own thread catching UDP messages and turning them into events to put on a queue to be consumed, which is basically what Volmarias is saying with the 'post messages to the UI thread Handler' pattern You should probably read this if you haven't already - it talks about what services are and the ways you use them. Briefly the point is to have a component that can run independently of your app (and could even be started by other apps), can manage its own lifetime, and is less likely to be killed by the system when it's low on memory. If you don't care about any of those things, and you just want it to scan for UDPs when the app is in the foreground and stop when it's not, then you don't need to abstract to a service This covers the whole handler/message thing which is fine for foreground stuff. The CodePath tutorials are generally pretty good!
|
# ? Jul 18, 2017 20:57 |
|
Volmarias posted:Without looking at or caring about any of your code, I'd like to point out that you can start a new thread from an Activity, it doesn't actually need to live in a service unless you'd like it to persist when the Activity goes away for some reason. baka kaba posted:Yeah if you're rewriting it I'd ditch the AsyncTask which is really meant as a quick way to do something off the UI thread and deliver the result on it. oh yeah I guess that's a great point, no need to abstract something like this when I can just have it run on it's own since nothing else will be using it. thanks for the tips and for putting up with my dumbass questions
|
# ? Jul 18, 2017 21:31 |
|
No problem. As an aside, is there a reason why you're setting up and tearing down the connection on every button press? Just setting it up once and leaving it open means you can just view the values. Does the broadcast happen too frequently and with enough variance for that to be feasible?
|
# ? Jul 18, 2017 21:51 |
|
Volmarias posted:No problem. That was the idea, the UDP messages are sent every 1/100th of a second and constantly changing due to a vehicle possibly changing position switching a potential alert from standard to imminent. I had it on every button press because the AsyncTask otherwise seems to crash the app when using a Togglebutton + while loop to check if the Togglebutton.isChecked() then running the AsyncTask from that Previous to your comments I wrote a service to handle the UDP traffic which runs on its own thread, and now that I have it binding it's not receiving the traffic so I'm making sure that i have it pointed at the right ports and all that jazz. FAT32 SHAMER fucked around with this message at 22:16 on Jul 18, 2017 |
# ? Jul 18, 2017 22:14 |
|
|
# ? May 15, 2024 17:15 |
|
I suddenly have a lot less confidence in self-driving car technology....
|
# ? Jul 18, 2017 22:30 |