|
brand engager posted:I didn't see any mention of it in the release notes. Anyways the trick to gradle is to use the oldest version that both has the features you need and isn't busted, and just dont update it until you absolutely have to.
|
#
¿
Oct 24, 2020 17:37
|
|
|
|
| # ¿ May 14, 2024 00:27 |
|
|
Did you search GitHub for Java/Kotlin projects that contain “import {libraryName”?
|
|
#
¿
Nov 24, 2020 04:01
|
|
|
imo it’s the only one worth using, and most networking libraries use okio for their basis anyways
|
|
#
¿
Dec 5, 2020 00:32
|
|
|
I want to say that when I set it up for my QA team I copied qemu.exe out then created a bat file on their desktop that launched it but that was a while ago. I’ll double check my folders on Monday and see if I still have it E; I think it was a folder they put on their desktop with the sdk with the batch file in there
|
|
#
¿
Dec 5, 2020 03:05
|
|
|
Tuxedo Gin posted:Newbie question: This is what I would do, so the play store can natively handle subscriptions etc: https://developer.android.com/guide/app-bundle/asset-delivery
|
|
#
¿
Jan 26, 2021 06:43
|
|
|
Tuxedo Gin posted:Thank you so much for the reply. I'll do some more reading and research into PAD. It checks a lot of boxes, though it looks like I have to upload everything in a pack to the play store, which means if I change one of the packages, I'd have to submit the entire app for an update. Is there any way to pull assets from my own servers so I can control them and make changes on the fly and handle the download/storage/update within the app? Or is that not possible for security reasons? Oh yeah that’s totally valid as well, especially if you’re already serving a website for the app or whatever. Just pull down data and parse it into a local db Vesi posted:trying to protect data from a hostile user who has root access, can edit bytecode and intercept network requests is pretty hopeless and wasted effort, just put data in Context.getExternalFilesDir(), smaller structured data into sqlite and have the app delete them when subscription is inactive Yeah pretty much this. Android has pretty significant security limitations compared to iOS, and while I guess you could hash the data and do various crypto stuff to protect it, I want to say they would be able to figure it out if the data is valuable enough. Could be a good way to protect it from low level pirates but I’m not sure how inconvenient that is for someone with the tools Vesi mentioned to crack
|
|
#
¿
Jan 26, 2021 07:25
|
|
|
We personally use 15 different pads to dynamically download image packages and display as needed so our base app is 15mb instead of 75mb, but I’ll admit you need to use reflection to access those files from your :app package and it’s kind of messy
|
|
#
¿
Jan 26, 2021 16:56
|
|
|
“Ok well I guess your IP is up for grabs then”
|
|
#
¿
May 14, 2021 06:41
|
|
|
Volmarias posted:... Parcelable's documentation is pretty explicit that this is a bad idea and that you should never do this. I'm impressed that someone did it anyway. You'd think whoever had this idea would have at least gone with serializable... real coding heroes figure everything out by stackoverflow questions and scrolling through function lists on objects that sound like they may do what they want
|
|
#
¿
Jul 21, 2021 14:09
|
|
|
brand engager posted:Does DataStore<Preferences> not work across processes? Getting the feeling that google really wants people to stop using multiple processes for a single app wasn't the point of DataStore to be asynchronous vs doing it directly on the UI thread? according to the docs (https://developer.android.com/topic...cB&gclsrc=aw.ds) you can run it synchronously and either scope the coroutine as blocking or scope it to the lifecycle of your current view. If you wanted to you could probably do withContext(Dispatchers.IO) { ... } inside of your launch lambda
|
|
#
¿
Sep 30, 2021 22:21
|
|
|
That sounds horrifying to maintain lol
|
|
#
¿
Oct 1, 2021 02:32
|
|
|
Your best bet is probably unity, which uses C# There’s probably other frameworks but Unity is the most common one I see
|
|
#
¿
Oct 9, 2021 18:54
|
|
|
does anyone remember how to make a material slider have discrete values but not multiple thumb thingos? i started out with Slider, but all you could do is set valueFrom and valueTo, while RangeSlider allows you to set a list of possible values such as listOf(1f, 2f, 5f, 10f, 25f), but then you have a thumb controller for each point, and i just want/need one
|
|
#
¿
Dec 2, 2021 19:11
|
|
|
Volmarias posted:I'm not sure what you mean by multiple thumb controllers? Stopping at certain points? It sounds like you want a continuous slider with an interpolator for what to map that value to. yes, exactly that the range slider has like n number of thumb slider thingos that lets you set a range (as the name should have implied to me!!), but i havent found anything that suggests how to do what you just described
|
|
#
¿
Dec 4, 2021 09:45
|
|
|
Based on what I’ve read, Compose is a great opportunity to begin migrating away from fragments, so brace urself for that
|
|
#
¿
Dec 15, 2021 08:04
|
|
|
Anne Bonny posted:Thank you! This solves my problem. However, now the end of the RecyclerView spills offscreen (The last row (or more?) of images is chopped in half). I get this problem all the time, and usually what I have to do is give it a moderately sized marginBottom with a constraint to parent bottom
|
|
#
¿
Feb 23, 2022 12:14
|
|
|
we're eventually going to switch to compose, but we're not too keen on the conversion process being convert xml -> compose with fragment, get all screens converted, then eventually convert all fragments to one activity that hosts all composables. and the refactor time on simply converting xml -> composables w/ single activity composable host is too big to justify rn and based on what i've read, doesnt play very nicely with having the activty manage both composables and fragments, and it breaks the poo poo out of everything if you use jetpack navigation
|
|
#
¿
Feb 26, 2022 22:24
|
|
|
compose navigation on the surface looks super promising since it's just a map of composables for the activity to begin displaying, and it would make sense that it would be more stable, especially for deeplinking, than the current xml jetpack navigation that does blackbox bullshit with fragment transactions that being said though, im not at all a fan of what as far as i understand is the use of URIs to handle deeplinking versus just keys, and i think the only really proper way to force developers off of xml would be to have an API update that deprecates Fragment and forces devs to compose, but i also would be willing to be that this wont happen at any point in the future due to the level of effort currently required. If they were to come up with a migration tool to convert layout files to composables, it would help, and if i understand the foldable api correctly, theyve made it a shitshow to do using xml. Speaking of the foldable lib, how hard is Android going into that? i think i saw docs saying that supporting foldables will be mandatory for all new apps, but it strikes me as yet another feature that nobody actually wants and not many people will have. Has anyone dug into that much?
|
|
#
¿
Feb 26, 2022 22:41
|
|
|
Volmarias posted:The change from MVC to MVI is a pretty rough one to try to shoehorn in, and I get the feeling that any generated results would be hideous at best. Wait MVI? What the hell happened to MVVM??
|
|
#
¿
Feb 26, 2022 22:55
|
|
|
brand engager posted:Does compose not have something to wrap an existing activity or fragment into a compose hierarchy? AndroidView only works for views, which isn't that useful since the activity/fragment and its viewmodel do the useful work on views Your option is to “inflate” a composable in a fragment (I.e. use the fragment as the composable host which is then hosted by your activity) and nuke any viewbinding and xml associated with it, or go whole hog and use your activity to host composables and map their flow using the new jetpack composable navigation and nuke all of your fragments and refactor large swathes of your view models
|
|
#
¿
Mar 18, 2022 04:29
|
|
|
Oh also after using it ive decided using uris for deep linking is fuckin nice compared to the PendingIntentBuilder
|
|
#
¿
Mar 18, 2022 04:33
|
|
|
Try using val onClick: (dataToSendToHostFragment: Any) -> Unit Instead of the callback method, then call onClick.invoke(data) from the root of the viewholder Note: Any is whatever the object you’re returning from the adapter to the fragment is
|
|
#
¿
Jul 19, 2022 23:26
|
|
|
Here’s a comment I saw a while ago that really resonated with me re: keeping state in the viewmodel/MVI in general: https://www.reddit.com/r/mAndroidDe...ossmf&context=3 I’m on mobile otherwise I’d try to embed the quote with the codeblocks
|
|
#
¿
Aug 3, 2022 23:52
|
|
|
smiling giraffe posted:ok try this: Wouldn’t it be lifecycle aware by way of the viewmodel? All it needs to know is if it’s active or not, and it’ll flow as soon as everything comes back after an onResume or w/e
|
|
#
¿
Aug 4, 2022 18:23
|
|
|
smiling giraffe posted:Done like this, I the activity is going to keep collecting even when in the background. There are flow operators like "flowWithLifecycle" that automatically suspend collection of the flow when not in the correct lifecycle state, which makes the flow act in a simlar way to LiveData. Oh derp, yeah if you don’t have composables in a fragment that makes more sense, ty 
|
|
#
¿
Aug 4, 2022 20:22
|
|
|
Put the text inside of the productState lambda?
|
|
#
¿
Nov 9, 2022 20:13
|
|
|
I have never mocked context before because those are usually called from a view, service, or application subclass, and we only unit test those via UIAutomator. I’m not sure if you’re using DI in your app, but you may need to mock the repository that is the intermediate between your firebase api call and the view you’re unit testing, or build a dummy class with fake data in your setup function Tldr if you’re trying to mock a function that takes context as an arg, you’re probably doing something wrong
|
|
#
¿
Feb 14, 2023 04:17
|
|
|
You’re going to need to mock context to call the initialiser extension, unless you linked the wrong one
|
|
#
¿
Feb 14, 2023 04:47
|
|
|
Yeah, sorry, I’m not. You normally call Firebase.initialize(context) from your Application subclass, and you seem to be stuffing a context reference into a singleton object, which is bad practice. Can you post more code so we have a better idea of what you’re trying to do and accomplish?
|
|
#
¿
Feb 14, 2023 05:10
|
|
|
I don’t think that will solve your issue, but you could give it a shot . If you’re only doing this for code coverage percentage then imo it’s not worth it, tho I’m sure someone else itt may have a better solution I have never successfully mocked Firebase poo poo before because as soon as you have it sorted to mock the firebase instance then you need to mock context and then you need to mock this and that and a bunch of other poo poo
|
|
#
¿
Feb 14, 2023 05:43
|
|
|
I googled it to make sure and I think I may be mistaking something, since you can apparently mock context nowadays
|
|
#
¿
Feb 14, 2023 05:49
|
|
|
The last time I looked into that, the options were either skeezy as hell, or more expensive long term than just buying the 3 or 4 most popular phones on the market rn. Ideally you’ll have a foldable (which is probably a Samsung), a non foldable Samsung, a pixel, and a OnePlus or Huawei depending on where you are in the world and where your target market is
|
|
#
¿
Jul 4, 2023 07:38
|
|
|
https://blog.pragmaticengineer.com/google-shutting-down-firebase-dynamic-links/ Classic google
|
|
#
¿
Aug 15, 2023 20:58
|
|
|
|
| # ¿ May 14, 2024 00:27 |
|
|
The same as 2020 but AS is faster and has some handy tools, Compose has made UI a lot easier, and some things are more stable or robust than they were
|
|
#
¿
Jan 12, 2024 02:14
|
|