Android Dev - Weekly "who's hiring" thread! |
- Weekly "who's hiring" thread!
- Weekly Questions Thread - November 25, 2019
- Add ‘Sign in with Apple’ button to your Android app | John Codeos
- Android Multithreading: Background Threads, UI Thread, Garbage Collector, Memory Leaks and More
- Free commercial PDF edit lib.
- Need to check if my grasp on OAuth2.0 in native mobile apps is correct
- Multiple application with only different API URL. [Application Design]
- app-ads.txt
- Modularizing your Android app, some quick notes (Part 4)
- I recently set up CircleCI and always receive this error when building. On Github and my machine (Win 10) the file looks fine. Any help would be appreciated
- This news story about Amazon reviews may be of interest to Google Play and it's search/review system
- LCD - A lifecycle aware Rxjava2 CompositeDisposable
- For simple apps that interface with an API, what are your thoughts on using nativescript?
Posted: 25 Nov 2019 04:44 AM PST Looking for Android developers? Heard about a cool job posting? Let people know! Here is a suggested posting template:
Feel free to include any other information about the job. [link] [comments] | ||
Weekly Questions Thread - November 25, 2019 Posted: 25 Nov 2019 02:56 AM PST This thread is for simple questions that don't warrant their own thread (although we suggest checking the sidebar, the wiki, our Discord, or Stack Overflow before posting). Examples of questions:
Important: Downvotes are strongly discouraged in this thread. Sorting by new is strongly encouraged. Large code snippets don't read well on reddit and take up a lot of space, so please don't paste them in your comments. Consider linking Gists instead. Have a question about the subreddit or otherwise for /r/androiddev mods? We welcome your mod mail! Also, please don't link to Play Store pages or ask for feedback on this thread. Save those for the App Feedback threads we host on Saturdays. Looking for all the Questions threads? Want an easy way to locate this week's thread? Click this link! [link] [comments] | ||
Add ‘Sign in with Apple’ button to your Android app | John Codeos Posted: 25 Nov 2019 03:28 AM PST
| ||
Android Multithreading: Background Threads, UI Thread, Garbage Collector, Memory Leaks and More Posted: 25 Nov 2019 04:24 AM PST
| ||
Posted: 24 Nov 2019 10:23 PM PST I'm shamed by my iOS colleagues for Android not having native libs to work with pdfs like they do. Particularly we need to view, highlight text and add comments. Any free for commercial use libs? Thank you in advance. edit: you can't just google it, there're none I've found so far. [link] [comments] | ||
Need to check if my grasp on OAuth2.0 in native mobile apps is correct Posted: 25 Nov 2019 06:52 AM PST Hello, I am in need of someone to verify whether or not I understand OAuth2.0 in native mobile apps (later referred to as just mobile apps) correctly. After doing some research, it looks like the best approach to implementing OAuth2.0 in mobile apps is to use PKCE without any client secrets. Client secrets are basically passwords that ensure that the client being authorized to resources on behalf of the user are legitimate clients that are allowed to do so (proving the identity of the client). Additionally, the identity of the clients also determine what resources can be sent to it. The reason client secrets aren't used in mobile apps is because they can be easily stolen from the app. If we can't use client secrets (or any other kind of password), we can not prove the identity of the client requesting authorization. This means as long as a malicious user has another user's credentials, they can use a clean version of the mobile app, punch in their credentials, and get the resources to their device. The PKCE extension for the Authorization Grant Flow ensures that the client sends a hash and hash function along with the authorization code request, and when exchanging the authorization code, it also sends the key for the hash sent earlier. This doesn't avoid malicious users stealing the authorization code, but it does render it useless to them, because they do not have the key needed to exchange the code for an access token. PKCE serves to protect against interception attacks, and ensures that the access token only goes to the original resource requester. However, it does not guarantee that the client is legitimate. Isn't this situation kind of bad for mobile apps? Especially for sensitive information? For mobile apps, it is impossible to prove the identity of the client, but this is not the case of web-server based clients. What can be done to help make this more safe? The only thing I can think of is to use multi factor authentication to increase the level of assurance that the client is legitimate. Thank you for your time. [link] [comments] | ||
Multiple application with only different API URL. [Application Design] Posted: 24 Nov 2019 10:30 PM PST Due to recent policy update of google one of our application got suspended. It stated: repetitive content violation. We have more than 150 client with exact same application. The only different things in these app are the logo and API URL. Now the problem is there is high chance of apps being suspended in future updates. Also the developer account might get terminated. Can anyone provide a solution to this issue ? Current architecture:API URL: Is this an architectural design fault ? Or is google just being an a**hole ? I need serious helps! THANK YOU! [link] [comments] | ||
Posted: 25 Nov 2019 05:57 AM PST Does anyone know if app-ads.txt allows for redirects like ads.txt does? [link] [comments] | ||
Modularizing your Android app, some quick notes (Part 4) Posted: 25 Nov 2019 01:20 AM PST
| ||
Posted: 24 Nov 2019 02:40 PM PST
| ||
This news story about Amazon reviews may be of interest to Google Play and it's search/review system Posted: 24 Nov 2019 09:58 AM PST This article on how Amazon's review system is gamed by paid reviews is enlightening. Much the same probably goes on as devs are regularly contacted via email by such outfits offering paid reviews etc. It highlights the difficulty of monitoring the integrity of reviews, and similar metrics that affect search ranks, ranks for certain keywords etc. Companies meanwhile use automated bots to counter, but some of the practices outlined in the article above are difficult to catch. Companies like Google use counter-measures, but they risk causing problems due to erroneous account bans, as their algorithms try to catch the last 20 percent of violators, they risk false-positives on average user accounts. This is the problem I outlined in my recent post about how automated bots that carry high penalties (lifetime bans) create a situation of moral hazard - because the fluid algorithms cannot be revealed, or may even be hard to describe, thus leading to "rules" that are imprecisely defined - at cost to developer: [link] [comments] | ||
LCD - A lifecycle aware Rxjava2 CompositeDisposable Posted: 24 Nov 2019 09:08 AM PST | ||
For simple apps that interface with an API, what are your thoughts on using nativescript? Posted: 24 Nov 2019 01:09 PM PST Sure, it's javascript, sure it isn't directly native, but it seems to save so much trouble - e.g. making a list view is a breeze compared to doing it the 'proper' way. I'm considering using it for for a few apps that would pull / push data to an API and would only need to present the data, and take in a bit of input from the user. Does anyone have any experience with it? Could you recommend an alternative over NS? [link] [comments] |
You are subscribed to email updates from Developing Android Apps. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States |
No comments:
Post a Comment