I've been checking out the Android Scripting Environment, it looks rather promising. But is it a viable option to make a marketable app in? It seems like the customer would have to download ASE and then run the script from the environment itself.
Given the lack of responses, I'm posting this more as a bump and discussion opener than a complete answer. My take is that SL4A might be good enough for small scripts, but not yet for full blown apps to update to the market. Just browsing the last couple of months of the discussion group page (link here), it seems that the API is still changing quite actively. I'm posting some examples below:
Issue 514 in android-scripting: Enhanced WebView API
New unofficial release
API Updates
Scripts as APKs
API Browser Changes
If you have a great script that you want to quickly port to SL4A, give it a shot. But I would not replace java with SL4A at least until it gets an official release.
Related
I know there's decompilers but decompilers doesnt work perfectly there will mostly some errors etc.
So like Whatsapp Plus, youtube vanced etc. How people modify apps? do they use decompiler,fix errors and then edit apps source code or do they use something else?
Some apps may have their source code available on GitHub, in which case you can fork the repository and apply your edits. Needless to say, you should always respect the license.
You can also submit bug reports to the maintainer, which would also be considered "good form".
If what you are truly trying to do is reverse engineer the app, you may find more info on hacker boards. I don't know many software developers who take kindly to having their hard work stolen.
Note that if you consider yourself capable of "fixing bugs" in apps that you haven't developed yourself, perhaps you would consider developing your own app.
In order for an app to be legally modified by a third party, the app must be open source (have the source code available to anyone), ex. Linux. However, the front-end source code of web apps, like youtube, can be viewed by anyone through browser developer tools. A decompiler can, sometimes, produce source code that produces the same result as the original, but is, most of the time, obscurified.
Isn't Branch really redundant, at least in Android? With questions like: Android - Is it possible to get install referrer programmatically
where we can do our own deep-linking, isn't Branch just another redundant tool now(at least in android)?
I can do all the things that Branch offers without integrating Branch at all.
Or am I missing something?
(Full disclosure: I did a Branch app integration last year and now work with the Branch team.)
This is a good question, and you're right: the deep linking landscape on Android has advanced quite significantly, especially with the introduction of App Links in Android M. As you mentioned, the Google Play Install Referrer (which Branch does also use) is available to anyone and passes a limited amount of data through the installation process. However it doesn't always get delivered reliably and isn't especially flexible. Many of Branch's partners had previously tried this approach and found it was too slow.
Branch does still offer a few benefits
Since there aren't really any deep linking 'standards' yet, Branch can still be a useful plug-and-play option for developers. Here are a few specific areas where Branch helps:
Edge cases
Given how many Android devices and OS versions are available, there are a ton of these. You’ll think everything is going great until you get that one user complaining that her links aren’t working on Facebook while running Android 4.4.4. Branch is currently tracking over 6000 of these situations (source), which can save you this nightmare and ensure that your links work everywhere.
Data flexibility
The Google Play Install Referrer lets you pass in a few strings via URL query parameters, but it isn't persistent storage and only works during the first install. Branch allows you to send almost anything you can think of (and also adds some useful analytics data), and it's available permanently with every link your users ever click.
Cross-platform
I know you asked specifically about Android, but if your app has an iOS version (or might launch one in future) then Branch makes it really easy to handle everything with a single system.
Value-added tools
Not deep link tech per se, but Branch can also let your users preview app content before installing, text themselves download links from their computer, and see detailed analytics for every piece of content inside the app, amongst others. Yes, of course those could all be developed in-house, but they're a big resource commitment.
I know it's kind of an 'open' question to ask but I simply don't know where to start. Let me first tell you a bit of my experience/background so you know the level I'm at:
Build cd-roms with Lingo back in the days
Started web/front end development in the HTML3.2 era and kinda left off when XHTML was hot
Worked with Javascript 1.2 up till around 1.6 and later started working with Jquery
Actionscript up to 2.0, building websites and games
Did quite a bit of PHP/mySQL development. Build custom CMS' and later Drupal module development
All this was during internships or as a freelancer, everthing self thought by the help of books and such
So now I'm stuck with this idea to build myself an app. I've decided it should be an hybrid app as my target audience is very small but 60% is iOS and I don't want to leave out Android. Also I've been getting familiar with HTML5/CSS3 and started working on components for my app.
The basic concept for the app is that it's a layer on top of Google functionality: profile, calendar, circles and hangouts. Users will (eventually I hope) be able to create events for other users to rsvp to, they will be able to add eachother as buddies and chat about the events. A small step functionality wise but a huge step for me :)
I'm thinking of using the Crosswalk project for the Android version to counter the biggest issues around hybrid app development.
I've been reading up for the last months in preparation and the more I read the less I seem to know. Here's the stuff I think I should know more about;
Node.js
Gulp.js
Dev environment to work in (I once worked in Homesite, later Dreamweaver - don't laugh)
Packaging tools, etc etc.
Crosswalk project
Now I am not looking for some drag and drop software package to build an app in 3 days. I don't want to take the easy route per se, I don't mind a bit of a learning curve. I work on a Win8 machine, I know this isn't optimal but I can't change this.
Now where should I start? I was thinking NPM myself but you guys might think otherwise. Any good books on the stuff you think I need to learn to get me going?
Thanx for the advice!
I can share my experience with Cordova.
I work like full-stack developer and i'm quite expert to build responsive website, so the natural step to approach mobile dev was try Cordova.
First You can start to build HTML document totally responsive and try as webpage on your target devices.
A cool stuff, targeting mobile devices, is that You can use new CSS3 directive, without worry for compatibility with old browser.
First I installed Cordova following this tutorial.
https://ccoenraets.github.io/cordova-tutorial/create-cordova-project.html
Opening the folder /www on your project you can edit your app like a website, and you can also debug with the browser like a normal site.
To enhance the feature you will find a lot of plugins ready on github to extends the native functionality at the Cordova/phonegap project.
I suggest you also to build using onsen http://onsen.io/ a framework that let you use mobile UI easily.
Last tip that i can give you, if you target Android is try your apps on virtual machine, i use Genymotion https://www.genymotion.com/ that is much more fast then SD<
Good luck with your first app!
As you can imagine, there are a lot of framework where you can start.
Looking on your skills, maybe is better to use JS/HTML/css stack, but in this case, you will create an hybrid app in a webview.
In my opinion, webview applications quality it's only acceptable, but because of his productivity, in some cases could be the best decision.
Another good alternative is react-native. This framework allows to create a native application using javascript. React has his own markup language, is very similar to html. JS code is executed on native device using an embedder javascript engine, instead of webview, so, performances and experience can be compared to native applications.
And, at the end, my alternative, a framework I've made to write native UI and share business logic for each platforms. You can take a look on aj-framework https://github.com/bfortunato/aj-framework
I work at a large company that is looking at building apps for internal use only (iPhone/iPad). We are looking for a SIMPLE way of creating apps that essentially are just a web browser with a predefined URL and no address bar/tabs, etc. Essentially a very dumbed down browser with a custom logo. What is the easiest way to accomplish this?
We would obviously be distributing these oursevlves and they wouldn't be available in the App Store, so app guidelines aren't an issue. We are on Windows boxes and are Java/Web developers so we'd rather not get into too much C sharp if at all possible, fyi. Basically it'd be nice if the tool (if one exists), were to allow us to give it a URL, an icon image, and it builds the app from there.
And while we are starting out with Apple devices, we need to be cross platform compliant with whatever tools we use because I can imagine the day when they decide to buy Android or WindowsPhone devices later on.
MobiOne? PhoneGap? Appcelerator Titanium SDK? Can either of these do what we need? Something else?
A big 'No' for MobiOne. I bought it for 99 dollars. As they advertised, I was able to create a static app within hours. But that's pretty much what MobiOne can do. The moment you start using html, javascript or even audio, all sorts of problem seem to creep up. And there is no support in their forums either. My basic question about using the audio player remains unanswered for a month now.
Here is the worst part:
The tool has a poorly built emulator. Often times, my app worked fine in the emulator but failed to run when deployed to a real device. And at times, i have seen the vice versa too.
Since then, I switched over to PhoneGap(which is free). It took me 2 days to just set my environment right. But once I had the environment setup, it took only minutes to deploy my app in to a virtual device.
Looking at your requirement, I would say that your safe bet is PhoneGap.
I don't have a working knowledge in Titanium but I read in a lot of forums that it supports less platforms when compared to PhoneGap. Titanium seems to give a more native feel to the app but that also means you cannot port it to multiple platforms without changing the code.
Apple may reject your app if all it does is wrap a web site in a WebView. You need to have more functionality in your app than just loading a web page.
From the app review guidelines for iOS:
2.12 Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected
You would need to add additional screens to the app like an about page and a contact us page in order for your app not to be rejected.
As you say you know JavaScript, look into appcelerator.com it allows you to build cross platform apps and only writing your code once.
I would re-evaluate your reason for wanting to create these projects as an app in the first place. What app functionality do you want that you don't have now with your web page? You didn't mention anything in your question that would indicate this needs to be an app.
On Apple devices, you could create an icon that points to a web site. You could define the pages in a way that hides the address bar. Lastly, the web pages could easily be cross-platform already.
Wrapping this into an app would just possibly complicate the process. You may need to deploy updated app code to the device, where a refresh in a browser works just as well.
At our company there is a huge push for cross-platform (iOS and Android) development. Appcelerator Titanium is being considered (and seems to be the only thing that's being considered) to achieve multi-platform development without extra development time.
Everyone here can think of reasons to use Titanium. For reasons against using Titanium I guess the performance of the resulting "native" app from Titanium may not be as good as an app written in Objective-C for iOS. How significant would the difference be? Are there other reasons to not use Titanium (or equivalent)?
Note: I may write Titanium but reasons may not only be Titanium specific only. All reasons in support for coding in platform language (e.g. Objective-C, Java) qualify.
The Good:
Can create iPhone apps using very simple Javascript.
The Bad:
Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api
"Native Widgets" are used, but only nominally: there's a layer of
logic and abstraction between them and your code; and this layer
changes their behavior and reduces their speed. The difference is
visible in the Showcase apps.
API docs are perpetually out of date. (no process for refreshing).
A wiki was created, which is becoming out of date. Editing only
allowed for employees.
Github projects do not have wiki enabled.
Appcelerator isn't true open source: they do not accept contributions from the community: The
titanium_mobile project on github has a long list of open pull
requests.
The help forum software has many technical & design weaknesses.
Email notifications from the help forum often do not work.
Staff rarely answers questions in the Q&A forum. Haven't been seen
in months.
Showstoppers appear continuously in "all the little gaps":
Correctly displaying images on the iPhone 4
Correctly loading images in a scrolling list
Although the platform does simultaneously support iOS and android,
the library/framework does not. A lot of runtime testing (if/then's)
is needed in apps that will work on android and iphone.
Continually releasing new products but not fixing existing products
and website problems. The "new" products are announced while in beta
and release candidate phases.
"Chat with Sales" app not attended to.
Appcelerator does not take down outdated training videos.
Stretching the truth and bait-and-switch with pricing: a 30% sale
only applies to yearly memberships, not month-to-month. The blog
posts & marketing materials do not state this. Only upon checkout is
this shown.
[Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
results for a search is trashed: each page of results orders its hits
from oldest to most recent, at the bottom of the page. Go to the next
page of results (i.e. 51-100), and again, the 1-year-old hits are
first, with 6-weeks-old at the bottom.
My Unanswered Questions:
[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff
and receive sub-par treatment.]
Results:
Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.
How significant would the difference be?
AFAIK, Titanium will generate Objective C, so unless their stuff is woefully inefficient, I wouldn't expect speed to be a major issue.
Are there other reasons to not use Titanium (or equivalent)?
Well, that depends on how you define "equivalent".
Personally, when I get into cross-platform apps, I expect that I will use PhoneGap. That's for one reason: standards.
With PhoneGap, you're writing HTML, CSS, and JavaScript, as if you were writing an HTML5 offline app. All PhoneGap does is turn that into an installable package (e.g., APK for Android) and give you opt-in proprietary APIs for getting to device-specific stuff. Their expectation is to simply fill in the "gap" between what HTML5 on mobile supports and what native apps on mobile supports. Heck, it's even in their name. :-)
As a result, what you are writing is the same sort of tech you would use for a Web-based app, and it may even get to share some of the client-side code. You can use whatever you like from mobile frameworks (e.g., Sencha Touch, jQuery Mobile). And, if someday app stores support HTML5 offline apps, you might even be able to drop PhoneGap altogether, if you're not heavily dependent upon the device integration features.
Titanium lets you write in JavaScript, but the standards compliance largely ends there. You're using proprietary APIs for everything, including the whole UI. Personally, I'd rather back a more popular horse -- HTML5 in this case, more so than PhoneGap specifically. If for no other reason, it'll be way easier to hire HTML5-savvy developers than Titanium-savvy developers.
Neither PhoneGap, nor Titanium, nor any of the plethora of other options (e.g., Rhodes, Flash/AIR) give you all of the device capabilities. These engines will vary in their extensibility -- I know that PhoneGap has a plugin model, that Flash/AIR is pretty much only what you get from Adobe, and I'm not sure about any others.
Titanium has one advantage: you get a near-native UI, instead of an HTML-based UI. (I say "near-native" because some of their widgets do not necessarily have native equivalents on all platforms, so they roll their own as needed) For some apps and some audiences, that alone may tilt things in Titanium's favor.
Titanium/iOS specific answer, my 2c.
Native iOS vs Titanium
PROS
It's nearly as fast as native for most things.
The time needed to write a working prototype it's way shorter.
If you need to integrate javascript legacy code or libraries it will work provided that it doesn't use the dom.
Your javascript code needs to be well spaced and to include semicolumns where needed or the compiler will complain and eventually abort the build.
You can use Coffeescript or any other language that compiles to js
Automatic memory management is top notch, getting the same results in objc is always time consuming and sometimes debugging intensive.
You can write your own modules in native code to extend Titanium's capabilities.
It's open source.
They recently changed their support offering removing the 5 app limit, much more affordable.
You can change a view js code while running the app in the simulator, you will see the results when you reload the view you're editing. That's a boon :) (exception: there's no way I know of to reload the code in app.js)
CONS
Debugging is a pain. Haven't tried out Titanium Studio yet, it might be a big improvement.
Adding too many views tends to degrade performance faster than using native code.
The Titanium Developer app on Mac has plenty of interface glitches and you might find yourself restarting it pretty often.
In some versions the print to console debug statements are broken.
You will often stumble into cross-platform abstraction leakage.
Support on the forums is a bit light, many issues you will encounter are not big but still annoying.
Need to pay attention to JSON correctness, the included parser tends to be picky. Using eval is always an option.
Compile times and loading in the simulator are not that fast, titanium objc is pretty big.
Compared to Xcode, Visual Studio & even MonoDevelop, Titanium Studio feels slow (real slow), buggy (restarting several times each day, even reinstalling a few times) and of course you've got to deal with JavaScript... We found that the pain of developing in Titanium was too great, especially when you have competent iPhone & Android devs around so -
We looked long & hard into the best option for cross-platform dev & ended up using Mono - Touch & Droid. It's been great, we do actually share 80% of the code between iPhone & Android, & we're just beginning a port to WP, which is going well (again sharing 80% of the code). Of course it's not a miracle fix - you still need to know how to develop for each platform. I've even grown to like C# almost as much as Obj-C now :-)
Obviously, some will disagree.