| I curated 850+ remote job openings from Hacker News who is hiring - February Posted: 25 Feb 2021 06:00 AM PST Here I would like to share more than 850 remote jobs that I've curated from Hacker News Who is hiring thread. All these are 100% remote jobs not just allowed to work from home during COVID-19. These are 100% remote jobs and will continue to follow that after the covid. https://remoteleaf.com/whoishiring. Note: Select "mobile" in the skills filter to view all iOS/Android development jobs ✅ 100% remote full-time jobs.
✅ Each and every job is manually curated and verified. Spent more than 30 hours for this. submitted by /u/abinaya_204 [link] [comments] |
| Is anybody else concerned about Google requiring the AAB format for new apps starting August? Posted: 24 Feb 2021 06:32 PM PST |
| Showing Charts in Android Applications Posted: 25 Feb 2021 06:02 AM PST Hi folks, I'd like to share a tool that I've worked on recently: http://getchart.me It's a simple tool that generates chart image from URL, in which you pass in Vega-lite chart definition into the URL and you get your chart back. Since it's just a URL, you can easily embed it in your app as you embed any other image. Hope you guys find it useful. submitted by /u/eckyp [link] [comments] |
| App Access to Customer Billing Info in Google Play Posted: 25 Feb 2021 06:05 AM PST Hi Everyone, If I use google play to sign up for a free trial subscription to upgraded services within an app, which requires me to put in a credit card on google play, does the app developer get to see the name, address, etc from that credit card? I know that it "tokenizes" the credit card number itself, but I'm trying to figure out if the app/app developer ever gets access to the actual name from the credit card used. If so, does it make any difference if the subscription is cancelled before any charges are actually processed? Any help would be greatly appreciated. submitted by /u/rmarcus123 [link] [comments] |
| Sharing data between a family of Android applications. Posted: 25 Feb 2021 01:23 AM PST Hi, I have two android applications, Let's call them App1 and App2. App1 is a system/priv-app application which is responsible to record videos using a USB camera attached to the device. (.raw is the extension of these files.) App2 is supposed to access the recorded Files and upload them to the servers. Both of these applications do other stuff too, but in context of this question, above information should be sufficient. Right now, I am using FileProvider and grantUriPermissions to get temporary access to these files inside App2. The problem with this is that these access rights are temporary and most importantly if App1 is not responding for some reason, App2 won't be able to perform the uploads. What I want to achieve is to remove any dependency on App1 to access the raw files in App2. Please help me with some ideas or references as to how it can be achieved. submitted by /u/shrish2784 [link] [comments] |
| Announcing Jetpack Compose Beta! Posted: 24 Feb 2021 09:32 AM PST |
| 3 Things I’ve Stop Doing Manually As An Android Developer Posted: 25 Feb 2021 04:44 AM PST |
| Google's Android Development Issues Posted: 24 Feb 2021 12:08 PM PST After watching 'The Android Show', I was upset and needed to rant about Android's developer issues. I understand that the Android Show was about the Jetpack Compose beta launch. But I feel that Google has failed to address a lot of the issues that has plagued Android development for years. This is coming from an Android Developer that has been around full time since Android version 1.5, made it a full time career, made it a part time consulting sidegig for almost 10 years, and has worked on AOSP. This is not to take away all the achievements and good things that has been done because I can name a lot. I obviously love Android development because I do it day in and out for so long. I am referring to the current state of Android development and how it could be better. I feel that Google has lost focus due to their business objectives and that Android itself has outgrown Google. Android development deserves better from this. But it will not get better since Google will not change it's business goals. From the last few years I can think of the following: Pros: - Switch to Kotlin - The language it self has pros and cons. But overall, this was a great move from Google to allow a third party language to be supported. Yes, I was super excited about this and it was a big surprise.
- Android Studio - This showed that Google took Android development seriously. This was overdue and should have been done from the start. This has helped with their tooling, integrations, and build processes as well.
- Google has kept Android Open Source - None of this "we control release and will open source it later or a part of it" like they did with Chromium project. They kept this true and allowed third parties to build and integrate their hardware with the Operating System.
- Tooling - Google has been great on this, adding a lot of build support and debugging tools. They are still superior in some ways compared to iOs development.
- Androidx - This shows that Google has trying to fix their fragmentation issues. I love the support libraries and they added a lot of needed libraries for easier and good development. This also decouples the code away from the OS level.
- Coroutines - This is not even made by Google. Coroutines are great and that adaption for it was also impressive. My only issue is that AsyncTask was terrible and so half-baked Google should have at least adopted RXJava or a better multi threading library sooner.
- Listening to the community - Google has done a lot better job than I would have expected and continued to listen to the development community which is encouraging. Even though there are still moments of doubt.
Cons: - Fragmentation still plagues Android - Not just on an API level. But on a developers' level as well. There are so many Android developers who know X,Y, and Z. But not A, B, and C. Perfect example, Dependency Injection. Some developers live by DI, while others have no clue what it does or how it benefits them. The con is that there are a lot of fragmented Android development in general. Not just on an API version level. If you ask some developers, they are still using Java for development which is more common than you think with legacy projects. Google's answer to this is their nano degrees and online certificates/courses which I don't think Google promotes or mandates enough of. Maybe make it a requirement to create a development account. But I can see that backfiring easy enough.
- Product integration - Google's business objectives are to make it easier to use Google products. like Firebase and Cloud. But not other products. Android deserves better in this regard even though Google wants to make Android development easier. But Google does not want to encourage other product integrations where they loose money.
- Android Things - This was really promising when it came out and exciting. But it has died like the rest of Google's projects. I still feel there is a big need and use case for Android Things and that it deserved more than just another dead Google product.
- Wearables - With the recent purchase of Fitbit, Google has more power and control here. But the problem is creating a standardized product that meets user expectations when it comes to this. The best Google has done is released a WearOS and build tools for OEMs and hardware developers. Calling it a day there is not enough. I would love to see more Android API's with this. Since WearOs did not meet Google's business objectives, the Apple Watch has come to define the user's expectations of a wearable. This feels like another dead Google product if it did not acquire Fitbit. So I guess we will have to wait and see what comes of this. I wonder if Jetpack Compose will support Wearable UI and Android TV as well? I have not looked into this.
- Deprecated APIs - How does Android development benefit the End Users compared to a web project or a Native react app? Why should a developer learn Android development if it keeps changing and that there is no difference from a user perspective in doing a simple CRUD web app. Deprecation has gotten out of hand and should be handled better in terms of maintainability.
- Application development Standards - Google has their 'develop this way' web videos. But how long did it take them to do that? Between MVC, MVVM, MVP, MVI Clean, there is no 'correct way'. Google has taken the MVVM approach. Yet, I know developers that are doing others. Should I use a Repository class? Do I really need Dependency Injection?
- Third Party libraries - There are so many great libraries out there for Android that is not even used or mentioned by Google development. They finally mentioned 'Glide' and 'retrofit' which are libraries that Google recommends using. But there are so many more libraries out there. I have used is 'leaky canary' for memory leaks. Yet if you search 'memory leaks' on Google they want you to use the memory profiler and inspect it manually. Square was developing better Android libraries than Google was for a time being. If so, Google should address this better instead of being sloppy with it. Conservative with adoption is different. There is a huge difference between 'vanilla' Android development and 'experienced' Android development.
- Documentation - This has gotten bad. This use to be great. Look at Activity/Service/Intents and you can find everything in Google's documentation. But now, there are so many Android versions, deprecated API calls, third party libraries. There are a lot of use cases that are not handle or mentioned. It would be great to have more example code and details rather than the simpler 'go to Sunflower example'. I don't want to be traversing Github or youtube when you have a dedicated website for this. It is like saying "we are too lazy to document so here is the code that will get updated since we don't want to maintain the documentation". There is just not a 'one stop shop' for Android development like it use to be. Remember AsyncTask? No, use RxJava, no wait, use Coroutines now, well there are 20 different pages on Coroutines. But not in the same place because it was developed by JetBrains, not Google.
- Beta releases of Android libraries - This is more of how Google develops their code and releases it out to the public more than anything. It has gotten really annoying and I am surprised how many Android developers still do not understand this or why Google does it the way they do. Perfect example is "Jetpack Compose". The point is Google's culture is to release early and often which is great from a user standpoint and has become the norm in software development. But it can also be damaging in multiple ways. As a developer, I would rather sit and wait for a stable release that is production ready than to find out it was replaced or deprecated. How many times do I need to change my code to go from findViewById, Butterknife, Android Extensions, to view/data binding (Yes I am aware that reference is not on Google's fault alone). My approach to 'beta' libraries has become like how I approach a new programming language: wait for wide-spread adoption, that it solves a problem better than an alternative, and that it is reliable for production use.
- Pagination - This is just one example on how Google has failed to provide easy, maintainable library. The API is not clear, not easy, and requires boiler plate code. When I did the codelab, it didn't even work. That includes pulling the completed github code down and running it. This issue has grown over the years. But it does seem that "Jetpack Compose" removes RecyclerView boilerplate code. But that is only one example.
- Beta hardware makes beta products - So Google did a good job fixing the biometrics API and consolidating this to a simpler API call (face/fingerprint all in one, cool). But Google is trying to expand and make money in it's a hardware division is where it has failed to create a great, integrated Android product. A perfect example of this, is the Soli project. It is ambitious and I loved the fact I could wave my hand to change it. But it came with a compromise, battery drain. Not only that it, Soli failed to get adopted by other companies. Since this turned out to be a bad experience for Google due to the battery drain, I doubt we will see this hardware come back and will not have future API support either for it. Google is great at taking chances to stand out in the market. But I don't want to be a beta user for a product nor develop for hardware that will not be supported in the future. This has happened so much that it has effected Google's reputation since they are becoming known for their dead products more and more.
- Legacy software support - Google is getting outdone here. In both hardware and software support. Apple has it easier with just updating to the newest and greatest. But I feel Google has gotten lazy in supporting devices. They claim they do 3 years of support for an API version which is great with all thing considered. But why is Samsung going above and beyond Google? With that said, Google should step up it's game here. But again, it isn't a Google business objective. So I doubt that will be mentioned. It feels that Google has lost control with Android and that other companies are taking Android more seriously in this regard.
Other / Discussion: - Rust integration - Not only add support for Rust for Android apps like they did with C/C++. But start building AOSP with it. I know they already added the Rust compiler to the build system which is a great start. But I would like to see this progress faster or some news on it.
- Kotlin Multi Platform library support - Google should take this project seriously. You took Kotlin seriously. Why not add more support for this? This has matured and grown a lot.
- Flutter? - Yes, question mark. Google is huge. Really big. I would probably joke and say 'bigly'. But you are sending mix signals here. Do you want Android development to go to Flutter and make Dart a first class citizen language for Android? I have used Flutter and there are some really great things here and some that still need work on. Google is a web company, so their business objective makes sense for Flutter here. But the point is, what is the game plan with Flutter and Android development? This isn't a pro/con since this is Android development discussion. More of, announce if this is the future here.
- Android development should be treated like Google treats their interview process, be very thorough and with great care.
// end rant submitted by /u/sloth514 [link] [comments] |
| Introducing Kotlin Multiplatform in an existing project Posted: 24 Feb 2021 11:52 PM PST |
| Nested recyclers done right! Posted: 24 Feb 2021 09:01 AM PST |
| How to send a message from Android smartphone to lite wearable using Wear Engine? Posted: 25 Feb 2021 03:18 AM PST |
| Intermediate: How to Integrate Location Kit into Hotel booking application Posted: 25 Feb 2021 03:17 AM PST |
| Great teams merge fast Posted: 24 Feb 2021 07:33 AM PST |
| How is the Android vs iOS situation in Spain? Posted: 25 Feb 2021 01:05 AM PST |
| Android Studio Arctic Fox Canary 8 available Posted: 24 Feb 2021 10:04 AM PST |
| Custom curves in Flutter, some guy has made an UI with just code and not asset images Posted: 25 Feb 2021 12:10 AM PST |
| Dependency Injection, Data structures VS objects! Posted: 24 Feb 2021 12:14 PM PST |
| What is the difference between R.file and Resources in android app dev? Posted: 24 Feb 2021 08:25 PM PST Learning app development and I was taught Resources consisted of mostly front-end stuff of the android app while you had java code doing the logic work, android app. on a high level was divided in these two parts. But now there is a R.file that contains identifiers for all resources in android app, but the R is also short of Resources? So does this mean there are two things by the same name in android dev? submitted by /u/zteman [link] [comments] |
| Android Dev Challenge : Jetpack Compose Posted: 24 Feb 2021 10:29 AM PST |
| Android Logging with Style Posted: 24 Feb 2021 04:58 AM PST |
| How are you handling CCPA? Posted: 24 Feb 2021 10:01 AM PST According to MoPub I basically have to tell the user that they need to use the existing phone controls for ads if they want to control ad stuff based on CCPA (on iOS, by enabling the "Limit Ad Tracking" setting, and on Android devices, by enabling the "Opt out of Ads Personalization" setting). I have a couple of questions. 1.- How can I detect if a user is in California? It is easier for GDPR, MoPub tells me and I also have a fallback based on locale. But California, how the heck can I know that? 2.- Does anyone have a sample of what they show on Android for CCPA to users? submitted by /u/mntgoat [link] [comments] |
No comments:
Post a Comment