This is often tricky enough for people on the same team but throw in distance, culture and varying levels of expertise and things get ugly pretty quickly.
I come across these issues pretty frequently and the pattern is constant enough that I reckon it deserves just a little bit of effort to jot down some practices to streamline things.
Go to the properties section of your Android app, then Android Options and set your max heap size to 1G (aka 1GB).
This one normally occurs when an existing version of your app is on the emulator and not being updated correctly to the new version you are trying to install.
In a very similar strain to the last point, this:// All of this was crap and I've changed my mind - but I might change it back later //Area Registration. When you put code in the repository – the flavour of source control doesn’t matter – the code was changed and short of investing a heap of effort (relatively speaking) by looking at individual file changes and trying to draw my own conclusions on the intent, I just don’t know what’s going on.
Now I’m fully conscious that this is one of those sometimes-religious sort of debates in terms of what constitutes a good commit message, but let me self-ingratiate for a moment and share some of my own from Pineapple Surprise: Each commit message succinctly tells you why the change was made an in some cases further embellishes with detail that’s actually pretty useful if someone else needs to come along and figure out what the hell is actually going on.
Let me give you can example: often I’ll see projects designed to be nothing more than an API that look like this: These are just a bunch of default Nu Get packages included in the Visual Studio template. No, you don’t need j Query in a project that only serves up JSON. Or probably a bunch of other stuff on those subsequent pages either. Because it creates an unnecessary burden on the maintenance of the project. Here’s another thing that’s minor if you know the project intimately and painful if you don’t: out of date packages. Here’s a tip: create a new Git Hub repository and add a .gitignore for CSharp: Now look at what the guys reckon shouldn’t go into the repo: In fact I’ve been known to write Subversion pre-commit hooks in the past specifically to keep this sort of thing out of the repo to great effect.
One possible solution is that the max heap size isn’t set (or sometimes loses it value).You get a lot of stuff in project templates these days. What often happens is developers compile then commit the bin and obj files to source control.I get it, pulling in smaller libraries that can be independently and organically evolved outside the framework itself is just great, but really, do you need all those guys?! Call them what you will but you’ll get a bunch of DLLs (and probably PDBs, among other files). A couple of years back I wrote The 10 commandments of good source control management and made it pretty clear in number 8 the sort of problems with causes: constant conflicts, polluted commits with all sorts of unnecessary files, repository bloat and so on and so forth.Or is that not important and he just didn’t think about it? Register Auth(); The solution is also the same – source control! Create a feature branch if you really want to head off in another direction but for the love of clean code, don’t pollute the main body of work that other people need to live in with a veritable brain fart of unused code! In fact as you saw in the .gitignore file, the bin and obj files really shouldn’t even be going into source control in the first place.Packages can cause breaking changes of various degrees: the other day I updated Auto Mapper to 3.0 and things broke but Jimmy had an easy fix. So how are you going to be putting dependencies in there?!
The concepts are pretty broad and generally interchangeable across technologies but I’m picking .