Hi everyone!
One of the crucial parts of app development is generating the actual buildings. You can waste a lot of time here installing Android SDKs, fighting with Gradle versions, and more shenanigans.
But implementing a Continuous Integration workflow with easy tools like CircleCI can save you a lot of time and effort.
Join me in this tutorial where we discuss how, by using CircleCI and the power of Docker, you can automate the generation of APKs in every Pull Request to your Github repository.
Simple Ionic app build automation with new CircleCI 2.0 -> softwareontheroad.com/ionic-circleci2?utm_source=xda&utm_medium=forum_post
Related
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Genericism
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Created 2017-10-06
Last Updated 2017-10-07
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases
Welcome!
Introduction
After three years of inactivity, of me (the developer) simply enjoying life and riding bikes, I'm proud to announce that JDroidLib is being resurrected!
Originally inspired by AndroidLib by @regaw_leinad, JDroidLib is a Java class library aimed to ease the development of Java applications designed to communicate with Android-powered devices.
The end goal was to make the library as easy and efficient to use as possible, and while the original library was easy to use, some fairly bad design choices were made on my part to make that happen.
After a turn of recent events, I've found myself to have somewhat more free time on my hands and decided to re-visit the project.
After looking through the (well-documented) source code of the original library, I decided that in order for an update to make sense, I'd have to completely re-write the library.
After a couple of hours of development and building the base, I had come up with a structure and code design that I was happy with and continued from there.
A few days after development began, I created a new repository on GitHub and thus, JDroidLibv2 was born!
The original version of JDroidLib was featured multiple times on the XDA platform and on other networks, as well.
Ok, great! But why should we care?
There are two very simple answers to this question!
If you're not a Java developer, or you have no interest in building Java applications that communicate with Android devices, such as flashing, rooting, or diagnostic tools, then you absolutely don't have to care! That's the beauty of it.
If, however, you are either of those, then you should give JDroidLib a closer look!
JDroidLib is designed to be efficient and easy to use.
Getting the library integrated in to your project is as easy as clicking a couple of times and calling it a day!
Now, I hear you ask: What's the upside to using your library?
Also a question that is very easy to answer.
Using JDroidLib, your application has next to no boilerplate code, meaning the footprint of your actual application is minimal and thanks to fast initialisation routines, your application will suffer minimal latency.
Thanks to both synchronous and asynchronous operations, your UI application will feel responsive to your users and your application less bloated.
JDroidLib includes shortcuts to commands that are often used and helper classes that cleanly sort and store data, so your application doesn't have to!
What design choices have you made?
JDroidLib is designed to be as easy to use as possible, while being efficient at what it does.
To implement these ideas and this design, JDroidLib uses a variety of designs that all work together to create an efficient library:
Factories to easily define the things you need
Singletons to prevent resource hogging and minimise the risks of memory leaks
Both synchronous and asynchronous methods so you can choose what's best for you!
Strongly typed
Provides features that otherwise prove useful in applications, such as tuples
Ok, that's cool and all, but when will it be ready?
As it is, JDroidLibv2 is currently in an early beta. Its features are not yet fully implemented and a lot of things are missing.
All I can say for now, is it'll be ready when it's ready.
It could take weeks, or even months - depending on how much time I have.
I'm hoping the repository will be updated regularly!
End notes
If you're interested in the project, the link to the source code repository can be found below.
In later posts I will add current features, todos, and more relevant information!
Happy coding!
XDA:DevDB Information
JDroidLibv2, Tool/Utility for all devices (see above for details)
Contributors
Beatsleigher, Beatsleigher
Source Code: https://github.com/Beatsleigher/JDroidLibv2
Version Information
Status: Beta
Current Beta Version: oct_17_beta
Created 2017-10-14
Last Updated 2017-10-13
Reserved
Current Features
Automatic initialisation
Installation/downloading of platform-specific platform-tools packages
Start/stop ADB server
Get list of devices
Execute custom commands (sync and async!)
Connect to and disconnect from devices via TCP/IP
Manage device filesystems
Get root and busybox information
Get device battery information
Current Todos
Complete Device class
Build file manager
Get battery information
Get SU/busybox information
Get CPU/RAM information
Build buildprop manager
Add reboot methods
Finish JavaDocing everything
Add (complete) wiki to GitHub
Add homepage to GitHub (I've no more website)
Add feature requests from potential users?
Continue updating
Elements that are stroked are completed/ideas that have been scrapped.
Reserved
Useful Links
Source Code
https://github.com/Beatsleigher/JDroidLibv2
Issue Tracker
https://github.com/Beatsleigher/JDroidLibv2/issues
Wiki and Guides
https://github.com/Beatsleigher/JDroidLibv2/wiki
Release Downloads
https://github.com/Beatsleigher/JDroidLibv2/releases
Todo: Upload to Maven Central
Social Media (Updates)
Google+
Twitter (not as regular, though)
JDroidLibv2 has been released in an open beta!
https://github.com/Beatsleigher/JDroidLibv2/releases
Hi everyone. I know that it's not a new subject, but I think it's a good subject to discuss about. It's the first question for any developer who wants to start a new project as everyday we can see new frameworks and languages comming up for development. After years of development now when I want to start a new project think about it again. It will be great if any one who has any experience can share it here. Because it's the experiences and times that show us if a decision was a good one or not. We can write about different parameters we considered to start a project, challenges and the results. Please feel free to add any other item you think is important to consider.
I start by myself:
Subject: A Network Communication App
Long/Short term consideration: Long term
Target platforms considered at start: android, windows
Target platforms implemented: after 2 years, android, windows, linux, (ios just newly started)
Framework: Qt5 (a cross platform framework)
Challenges: We used a crossplatform framework but as you know any OS has it's considerations and styles for development. Also different frameworks have different capacities for handling these features. In this project one of the challenges we had was the way android handles services and activities. We had to separate our UI from the logic controllers completely and implement a way to communicate between these separated processes. Also we had to implement the OS based features separately for each OS like notifications and alarms. Fortunately Qt let you use native codes for these specific features. For example you can use native java codes for showing a notification or playing system native sounds and alarms.
Pros: We implemented our UI just once and used it for all platforms. Also we implemented network and controller threads once and used them for all platforms. In this way if we need any change in our protocols or UI, we just develop them once. So we have one development team for all of them.
Result: Cross Platform with Qt was a good decision at that time for that project. Specially for a small team like what we had, because after you implement the base of a project like this you have to support it for a long time and add features to it. If we were using native codes, now we had to have separated teams for developing new features and supporting it.
It's great to read about other people stories. So Please let us know about them.
Thanks
Native vs. Cross-Platform
Native apps are developed only for a specific platform. These apps are formed in a language cooperative with the platform. Apple, for instance, prefers Objective C and Swift for iOS while Google supports Java for Android. Using these satisfactory languages, developers can create safer use of the inherent features of these platforms. A native app developed for Android will not function on iOS and vice versa.
Cross-platform apps are cooperative with various platforms. Due to the market share of Android and iOS, most cross-platform apps are confined to these two operating systems. These apps are produced in HTML and CSS since these official web technologies are platform-independent. Several cross-platform application development tools enable developers to create these apps with little trouble.
I've been working on my own assistant application framework for some time now, and I am coming up to a point where it is functional for an alpha release. There aren't really any other FOSS assistants on the market other than Mycroft, and I noticed that there is no development happening on Saiy/Utter!.
I've been developing it heavily using a Unix mentality which is meant to reduce the mental overhead when it comes to creating skills or new/replacement modules. I paid a lot of attention to the development of the framework so that individual components can be developed or replaced independently, allowing it to be more of a platform than a standalone application. This should also allow it to be easier to dive into individual parts of the application.
There is still a lot to go in terms of making it useful out of the box, but it's almost all there in back end, and I think I'm finishing up the concrete features and flags that it needs to operate with skills and modules that other users develop.
As it is right now, it does offline speech recognition using Vosk STT, and intent matching/entity extraction using the Stanford Core NLP library. I have it set up with a mock Calendar Skill to test its matching and finalize how I want it to interface with complex tasks. Currently it *WILL NOT COMPILE OR WORK* since I am still working out bugs on the alpha. When I am ready to release an actual alpha I'll branch the code, and I'll post/host nightlys somewhere (maybe also put it on F-Droid and Google Play).
I intend to interface it with Termux/Tasker, Google Assistant, Alexa, and Mycroft, as well as at a chatbot feature, but those are all secondary to the task of a stable working assistant/platform. I encourage feedback and questions about how it works and how it could be hacked on to do other things, so that I can write documentation that is as transparent and understandable as possible. Hopefully the code is a bit self documenting as well. I strive for readability over cunning.
Here's the link: https://github.com/Tadashi-Hikari/Sapphire-Assistant-Framework
Let me know what you think
I have recently been developing a middleware library that helps you to develop mobile applications, faster and easier than before. Finally it is live at https://topping.dev . This project started in 2012 to reduce time developing applications on android and ios platforms by creating a topping layer on mobile operating systems. All you need to know is how Android layout XML works and basic Lua or Kotlin knowledge. After developing it from time to time, I decided to make it open source. The project is in beta stage but most of the functions work. With the help of the open source community, I hope it will expand and grow and become the best of its kind. Also there are WPF and Web proof of concepts at github. http://github.com/topping-dev