I am extremely new to mobile developing and have recently been put in charge of updating a React-Native app using Expo, that hasn't been touched in about 18 months.
I am familiar with creating web applications or websites from scratch and thinking about debugging from a creation standpoint with updated code that is not deprecated but the idea of updating old code is foreign to me.
Can someone help share their thought process when it comes to this?
The mobile app itself runs alright - crashes and malfunctions from time to time.
Is the idea to go in and see what code is deprecated and which dependencies need to be updated? And/Or is the idea to try and find what is making the code crash and malfunction and leave deprecated code and old dependencies?
Thanks for your patience with what seems like a silly question.
And/Or is the idea to try and find what is making the code crash and malfunction and leave deprecated code and old dependencies?
It is typically recommended that crashes and malfunctions should be resolved before updating libraries. Some libraries may introduce further crashes and errors after upgrade due to breaking changes and deprecation. As such it would be difficult to separate code bugs from errors caused by library upgrades.
If some of the bugs and crashes cannot be resolved without library update, then fix as much as you can before updating the library.
Is the idea to go in and see what code is deprecated and which dependencies need to be updated?
This question is subjective. It depends on how much time can be spared for the upgrade process. Obviously, updating libraries can have other small benefits like improving performance or reducing code size etc, but if a library that is used extensively in code (eg. react-navigation) has not been updated for many major releases then update/ refactor and testing will take a long time and may not be worth the time if nothing is broken.
Furthermore, it is easier to update libraries regularly and frequently rather than wait for the current version to be deprecated. This way, we avoid having to deal with tons of breaking changes in one go.
Related
We are using webdriverIO version 4 in a quite a few frameworks where I work. While undertaking the review of one of the frameworks, the option of upgrading to version 5 was recommended. However, the framework is not the most straightforward and there will be a lot of manual fixes needed to commands in many places and the time needed for it is just not known.
Hence the question, what is the risk if we don't upgrade webdriverIO at all? Any dependencies stopping successful builds or browser version incompatibilities affecting test execution? And how soon are these likely to be realised.
Any pointers that can enable this review will be great help.
One of the major risks of not updating over the long-term is Node version support dropping. As new versions of Node are released, you'll likely want to upgrade to the latest. However, since older versions of WebdriverIO won't be tested on these new Node versions, there may be incompatibilities between the two.
Apart from that, other drawbacks include:
Missing out on important new features. For example, WebdriverIO v6 includes 'waits' by default now, so you no longer have to include so many "waitFor" commands, and your tests will be less brittle.
Security Updates via dependencies. While not as important, considering tests aren't normally public facing, it's still nice to have the latest features available.
Unable to make feature requests. There's a very low chance that you'd be able to get any new features added to old versions of WDIO, especially v4. This means you'd have to do it all yourself.
Less likely to get help. If something breaks or you're in need of outside help, being on an older version will hinder any help others can provide as they'll be much less experienced with it.
I've upgraded many test suites from 4 -> 5 and while it wasn't the easiest transition, it was also very doable. Unless you have something very complicated going on, I'd put the upgrade at a week tops. It took me about a work day or two to update mine, but it wasn't the most complex code (on purpose).
I have seen many videos of code changes to a controller and then refreshing the page showing the update very quickly (1-2 seconds) and everyone is always talking about how fast Roslyn is.
I have just installed VS2014 CTP3, created a web application, hit run and then edited the message Contact action method returns.
When I hit refresh in my browser, the page takes about seconds to load (the first time, after that its instant). This the app pool starting back up and recompiling the code, but this seems a lot slower than what I have seen others experiencing.
Is anyone else having this? Could it be doing a full recompile rather than a partial recompile each time? Does anyone know how I can find out what is causing the slowness?
Thanks
I think most of the time the speed of Roslyn is compared to the speed of the previous source to il compiler. In the previous version of .NET you always pre compiled everything to il (a .net dll) which will always be somewhat slower than not pre compiling. This performance loss might be mitigated by performance gains in the il to native engine which is currently also being optimized. Depending how much needs to be compiled, jit compilation might still be to slow for your situation, so you might need to pre compile some files and or libraries.
Looking at recent merged pull requests and the fact that Roslyn is still in beta you might see considerable performance gains between the current alfa release and the RTM.
https://github.com/aspnet/KRuntime/pull/522
https://github.com/aspnet/KRuntime/issues/498
When the developer of an API, e.g., Microsoft, Apple or me, announces a feature of the API is being deprecated, how long should the API developer wait before removing the feature from the API?
From the other point of view, how long should a user of an API expect to have to refactor code after an API feature is marked as deprecated?
If you move from version A to B, you should directly remove deprecated methods.
Unless you know that you won't need later upgraded version then you may keep what's working.
But as every problem, the sooner you take them on, the easier it'll be.
It's usually easy enough to change deprecated code from version A to B, but if you cumulate modifications, it'll be a nightmare
Once you discover APIs that are marked as deprecated, you should start looking to update your software to replace them with non-deprecated methods. If you continue to use them, you run the risk of your software not working on newer versions. This is fine if you never plan on upgrading, as evidenced by the multitude of Win 3.1 software still in use. However, if you are going to be supporting the software or releasing new versions, you should update as soon as feasible.
Usually, the API never removes features due to the fact that some programs will be rendered useless if they rely on a certain method. But if the method is honestly useless or contains a lot of bugs, they remove it after two or three updates.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
I use Intellij Idea 7 for Java dev. My dev is 'limited' to all J2SE features plus light JSP, Servlets, and super light usage of JPA. No J2EE, no massive use of random frameworks, etc.
Is it worth upgrading to ver 8? "Worth it" to me means better "core functionality" in terms of speed (ESPECIALLY startup speed), memory utilization (seems like it starts having serious problems with four or more projects open), and auto bug-finding.
More frameworks supported and more languages supported (other than perhaps Haskell and C++), and more refactorings don't interest me at this time.
A while back, I installed a preview version of 8 and it seemed -exactly- the same as 7, as far as my needs were concerned.
Anyone loving the upgrade to 8, and if so, why?
Thanks
It also seems to be easier to configure a new project over top of a complex collection of existing code.
For example, something that you would naturally configure into 5 or more modules.
There is a really beautiful go to/create test wizard that is bound to ctrl-shift-T. Worth the upgrade by itself
The best way to tell is to check out the list of new features and decide for yourself. I haven't discovered any single feature so far that by itself is worth upgrading - the simplified UML view is quite nice, as is the improved Maven integration. The UI feels a bit more streamlined and faster. It seems like most of the attention has gone into non-Java features like better Flex support (which I am really thankful for as I don't like FlexBuilder but I haven't had a chance to use yet).
IntelliJ 8 has a configure plugins feature that allows you to disable plugins with dependencies. Nothing trial and error couldn't replicate, but it is nice.
Startup is only marginally slower. But indexing once opened is a lot faster than before, even unnoticeable for most projects, except after a commit to Subversion. It seems a commit to subversion triggers the indexing twice.
I am working on the Diana-EAP build - but 8 has git integration built in. The EAP has better git integration than the 8.0.1 release - it looks like that is something they are really focusing on.
Definitely not! Seems that the variables defined in our custom taglibs are no longer able to be used in the jsp (worked in 7.0.4). All red. No auto complete.
Oh, and the new settings menu is horrendous!
Some benefits of IntelliJ IDEA 8:
IDEA 8 supports Subversion 1.5 new functionality - e.g. merge tracking, which may be useful especially if your team (like ours) uses a lot of development branches and thus merging is frequent.
One detail I appreciated about IDEA 8: As you probably know, IDEA has had changelists for pretty long now, built on top of any underlying version control system - this is a really useful feature. So, now that Subversion itself supports changeslists, IDEA's changelist implementation has been changed so that it is perfectly compatible with Subversion's native changeslists. (For example, you'll be able to work with any changelists created in IDEA also when using svn command line tools directly.)
Edit: in your case, perhaps it is not worthwhile to upgrade. For me, at least, startup and file indexing seems to be somewhat slower in 8 than 7. [But for me personally the upgrade was definitely worth it, because it solved a long-standing VCS problem with IDEA 7 - it could hang "waiting for VCS sync to finish" for an hour or whatever after hitting Ctrl-K.]