I'm new to Xamarin/Android, and so far it's been a pretty frustrating experience, compounded by code/AXML changes seemingly not being built or deployed to the emulator. I often find that a change I've just made seems to get ignored when I build and run the app.
My suspicions were confirmed when it started throwing an exception on a line in MainActivity.cs that I had commented out. Cleaning and rebuilding didn't help, and in the end deleted the bin and obj folders and uninstalled the app off the emulator for good measure (not sure which of these fixed it though).
Is it just me or is this a common issue? Is there anything I can do to prevent it from happening? I'm using VS2015 Community by the way.
Go to 'Tools/Configuration Manager' and make sure that both 'Build' and 'Deploy' options are checked for 'YourApp.Android' for active solution configuration and active solution platform. Then do 'Clean solution' and 'Rebuild solution', it should always work.
It looks like this is a common issue, as yet unresolved.
One of the comments in the above thread suggested that the problem can occur if you've only changed C# code, and unless you also "touch" one of the xml or axml files then the latest version won't be deployed. This seemed to do the trick in my case but it could have been a coincidence - Xamarin seems to be a temperamental beast, and will randomly fail to build or deploy on occasion, perhaps depending on the wind direction, or colour of my underwear that day.
I'm still in the early stages of learning Xamarin/Android, but if I don't enjoy the experience then I'll be jumping ship to Android Studio (although I'd prefer to stick with C# if I can).
Related
First of all, I'm sorry to ask a somewhat vague question but I'm only doing it because I'm clueless to what might be causing the problem.
I've been building an app with Sprite Kit and it has worked great. I've made some additions to code at suddently I see a dramatic decrease in performance. I have rolled back all my code changes but the performance didn't go up. I'm left clueless to what's wrong.
After hidious debugging I've noticed that the performance problem only affects run and test builds. If I do a profiling build, the app behaves as normally = with high performance. So this would suggest that my problem is somewhere in the build configuration but I'm completely new to ios build environment configurations.
Can anybody suggest what might be the cause of this? Where should I start looking? I have my background in Java 5 and the compiler and other settings are quite strange to me.
The default setup is to have a Debug config and a Release config, where Debug is configured with no optimizations, and Release does include optimizations. Optimizing often makes it hard to use the debugger, which is why unoptimized code is preferred there.
By default, Run, Test, and Analyze use the Debug config, Profile and Archive use the Release config. Your change in behavior could come from lots of differences: you may have had it configured before to build for Run in Release mode. You may have had a subproject built in Release mode that is now in Debug. You may have made a coding change that is very slow unless the optimizer is used. (Since you say you rolled back the code, this last one is unlikely, but check your version control and see if you changed any project settings.)
If you're seeing weird "it wasn't like that before" behavior when you think you've put everything back, make sure you're rebuilding everything. Delete your Derived Data directory. You can determine where it is in Preferences, Locations. "Delete your Derived Data directory" is the Xcode-equivalent of "try rebooting." It's the most common way to fix strange "Xcode isn't working right" problems. In fact, I put my Derived Data in /tmp/build so that it gets deleted every time I reboot (and so the path is easier for me to remember).
I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
we are using Grails together with Maven and Intellij. For the beginning of the project it worked everything nicely. Now we are getting more and more strange effects like when somebody is checking in wrong code, some are getting error some are not.
Are there any best practices to config IntelliJ so thats it working on each machine good and predictable?
We found out that some having the "make" before starting the project disabled but this didnt solved the issue.
Thanks for your help!
Got very little problems in 2 years. Idea had couple of cache issues a year ago, I wiped caches by hand. Ever since then, had no problems with caches/indexes.
Couple of things I could think of:
grails clean usually fixes most weirdness;
Yes, removing "Before launch - make" flag stops Idea from doing wrong guesses and unnecessary compilation (which id does differently from Groovy compiler);
For every new run configuration, we add ValueFormatter to VM parameters, or add it to Grails defaults;
Create a run configuration for test-app and run it on regular basis;
Give it as much memory as you can in idea.vmoptions.
My Delphi installation has been going downhill for the past few months. It seems though that every so often when I build a release it has strange errors in it which are resolved if I build, then compile, then build, compile, etc.
I've talked to another developer who thinks that this is a compiler error. This sort of degrading performance over time has happened on other computers to us too.
What does stack overflow think could be the problem.
What I've seen most is a case where multiple versions of the same units/dcus exist in different folders/paths, and depending on almost insignificant variations the compiler/linker uses a different path and picks different versions of the units to build the exe.
I would make a huge Spring clean-up, scrutinize the lib/search paths, remove all dcus and make sure there is no duplicate versions of any unit.
And, agreed, reinstalling Delphi could help start with a clean state.
I agree with #François about the DCUs, but also want to point out an observation: sometimes it matters what was built prior to what you're building. i.e. if you have several projects that contain source code that results in various .dcu/bpl files being created in a common directory, but the project that you're concerned with doesn't explicitly call for them to be rebuilt, then you're going to end up with whatever is there. If you clear the dcus/dcps prior to building, and then find that your project doesn't build, then you are missing a uses/requires clause somewhere. Every project shoudl be able to build on a "clean slate", and not rely on leftover binaries.
That's not much to go on, but it sounds like a classic case of "bit rot". Too many things interacting in too many ways for too much time under a poorly-designed OS, leading to strange forms of data corruption.
First thing I'd do is uninstall Delphi and reinstall. If that doesn't work, try reinstalling Windows. (If it's been around long enough for this to be happening, you're probably due for an OS reinstall anyway.) And if that doesn't work, contact Embarcadero tech support.
I'm developing an application on two different machines (home and work) and while the home one seems to run just fine, the work one is, for lack of a better word, possessed. It has been exhibiting the following issues:
When loading the application, it will start at the simulator's main screen instead of starting the application at random intervals. You can start the application and have it work fine, then close the simulator, reload, and have the same codebase not load.
Going to applications doesn't show the application itself, in fact it never does.
Trying to load the applications cod file (File->load java program) never works. Tried the steps in this thread, with unreliable results.
Extremely small changes, such as modifying the value of a width variable by one, commenting out a function such as makeMenu or adding a button will cause code to no longer work, with no errors shown by the IDE.
Using clear.bat with sometimes work, sometimes not. Same with manually removing all files with the name of the project.
reinstalling the eclipse environment and the blackberry plugin did nothing more then burn off an hour.
having "load on startup" in the blackberry_app_descriptor.xml file is set.
Both systems are using Eclipse 3.5.1, BB plugin for eclipse 1.1 beta, Java 4.5 with the 8300 simulator. THe only difference that I am seeing is the operating system between the two systems. The work one being XP Sp3, home being vista. THe vista one isn't perfect, but I can test variable changes without flipping a coin to see if the app will even load or not.
I've tried the solutions that were similar on this forum, such as this one, but it looked to be that those solutions are dated as none of the options for the steps existed in my eclipse install.
So has anyone ran into such baffling behavior, and can it be fixed? Anything that I might have missed that could be tried?
I've been seeing this behavior with the new 1.1 plugin, the application doesn't load on startup and the FIle->load java program doesn't help. For me, the solution was I have to run a clean build every time, that is the eclipse clean and build instead of just build, not the clean.bat... Hope this helps!
Try clearing resources that have improper naming structure in your projects stuff with spaces or special character in the name of the file.
It took me two days to figure out.
One solution i got regarding your problem.
As I See Please run the application first time as Run as blackberry simulator
that is got start and here pick up run and then Run as Blackberry simulator