The answer to all these questions is mutation testing. Interested? Read on

Code Coverage – Our Old Friend

You probably know what code coverage is. Traditionally, many teams tend to measure how good their tests’ suite is by percentage line / statements / functions coverage. Some even require this metric to be 100%. Let’s start with this well-known approach first.

We are working with TicketsPriceCalculator class today. It contains some simple business logic:

As you can see, the class has one function whith returns the total price to be paid for a set of tickets. On the way, it applies various discounts based on some business rules. Fair enough.

It’s a critical piece of business logic for the app we’re working on, but it has never had any tests. We were asked to write unit tests for this class. Our manager strictly requires the code coverage to be 100%. Let’s do it then. We will go line by line, analyze the business logic and add the tests. Below, you can see the results of running those tests (you can find the tests code here):

Wow, that’s awesome! We did a great job. We have 8 unit tests which provide 100% statements, branch, functions and lines coverage!

So now we are really safe, aren’t we?

Yeah… until you know what mutation testing is

What Is Mutation Testing?

The idea of mutation testing is to mutate (change) our code. Mutation testing tools introduce changes into our production code. These changes can be really anything – from reverting a condition of an if statement, to changing some operators or changing a string value. For instance, here are some logical mutations Stryker Mutator is able to introduce (you can find the list of all mutations supported by Stryker here):

In effect, they generate modified versions of our code, which are called mutants. Makes sense

Each mutant contains a single modification in our source code. What happens next is crucial. Mutation testing tool takes this mutant (it is used as the code under tests now) and executes all of our unit tests against it. The result may be twofold:

• all tests have passed. In other words, the mutant has survived. This is a bad situation. It implies that the modification of our source code was not detected by our tests
• at least one test has failed. In other words, the mutant has been killed. This is a good scenario. It means that our tests detect changes in the production code and efficiently cover this particular scenario.

The flow is more or less like this schema from Peter Evans’ blog presents:

But why would anyone change the production code on purpose by introducing some stupid changes? It may seem counterintuitive for now, but let’s see how we can use it to our leverage.

Mutation Testing with Stryker Mutator

Let’s clearly state what we are starting with:

8 unit tests, 100% code coverage

Let’s now run mutation testing on our code. We are using TypeScript here, so let’s go with Stryker Mutator.

Here’s the result of running Stryker with npx stryker run on our code:

As you can see, 53 mutants were killed, but 15 of them survived. This gives us a mutation score of 78%. Let’s call it mutation coverage from now on. So to make it clear, this is our starting situation:

8 unit tests, 100% code coverage, 78% mutation coverage

Let’s now see how to kill those remaining mutants.

Killing First Mutants

In order to kill the mutants and improve our mutation score, we need to write more unit tests. Sounds logical, doesn’t it?

If still not, let’s take a deeper look at mutation tests results in VS Code. Stryker lists details of every survived mutant, for example this one:

Stryker changed the greater or equal (>=) operator to greater operator (>). This is a very common and very useful mutation. It usually means that our tests don’t cover the edge case associated with this particular condition.

In this case, the edge case value seems to be 5. More precisely, what happens if the number of business class tickets is exactly 5? We don’t know, because there is no test for this particular edge case!

Let’s add it:

The test passes. Let’s run mutation tests again:

That’s it! We have a new unit test and 1 more mutant killed Current state:

9 (+1) unit tests, 100% code coverage, 79% mutation coverage

I think you’re now getting what this is all about. We should be adding unit tests to cover the edge cases detected by mutations until all (or most) mutants are killed.

Mutation Testing – Free Unit Tests Generator

After adding 1 more test, the results look as follows:

10 (+2) unit tests, 100% code coverage, 86% mutation coverage

Finally, this is what we managed to get after a few minutes of work:

And we now have 17 unit tests in our suite! The final score looks like that:

17 (+9) unit tests, 100% code coverage, 96% mutation coverage

Notice what happened here. We started with 8 unit tests and finished with 17! This is awesome! That’s how mutation testing is a free unit tests generator. And you don’t even need AI for that

What’s more, the generated mutations even forced me to make a little tweak to the production code. It exposed some things that didn’t make sense. I could make this change to the production code, because my tests’ suite was already quite substantial.

Note that I didn’t push to gain 100% mutation coverage. The 3 mutants that survived don’t make much sense in our case. I encourage you to get the code and execute npx stryker run in the application folder to see for yourself

The percentage value doesn’t matter in that case. What matters is that we got 9 new unit tests and our tests’ suite is more robust. Now we can go and tell our manager that the business-critical code is well tested

So What Now?

I hope you see how valuable mutation testing is. It’s not a perfect tool that suits all cases. For example, it’s not easy to use mutation testing for complex legacy code. However, if your logic is nicely isolated, it could be a great tool. Especially if your production code heavily depends on calculations and many conditions. You may be surprised how many edge cases mutation testing can find.

I also love using mutation testing with TDD. These two techniques nicely complement each other.

I encourage you to go and try mutation testing. There are different mutation tools for various programming languages:

• C#, JavaScript, TypeScript, Scala: Stryker Mutator
• Ruby: mutant
• Java: pitest
• PHP: Infection
• C++: Mutate++

…and probably many more. Just do some research for the language you work with and give it a try Because testing is cool, isn’t it?

You can find the full source code used in this article here.

The post What is Mutation Testing and Why Should You Use It? appeared first on CodeJourney.net.

If you ever had an API action defined like that in your controller:

and fetched this data using TypeScript in the following way:

at some point, you probably also experienced the desynchronization of backend (C#, in our example) and frontend (TypeScript) types definitions. What if someone has changed the C# version of UserViewModel, but no one corrected its TypeScript’s equivalent?

Your TypeScript fetching code will tell nothing about that. There will be no error, even though the fetched data doesn’t match the expected UserViewModel type.

I’ll try to address this issue in this article Let’s see how typing API responses with zod can help us here.

Synchronization of Backend and Frontend API Typings

First, why would we want to keep the backend and frontend models in sync?

For me, that’s the purpose of using TypeScript. We want our code to be as well-typed as possible. For instance, we normally want the data displayed to the user to be fully typed. TypeScript enhances our programming experience by providing us with typing information. Thanks to that, we know what is what and what contains what. We also express what types of data we expect in particular cases.

The APIs mostly return JSON data, which can be anything. Because of that, it is much easier to have the data returned from the API fully typed in TypeScript. Thanks to that, we know what properties are available on the data models received from the API and whether we can use and display them to the users.

The sample code used within this article is available on GitHub. We will use ASP.NET Core (C#) and React (TypeScript) apps as examples.

Models synchronization example

As we saw in the beginning, a classic example is an API controller that returns a strongly-typed data:

The returned data type is a collection of UserViewModel objects. Here’s the C# definition of this type:

Its equivalent is also defined on TypeScript side:

Usage in TypeScript

Cool. With this simple code, we can create a usersService.ts file and fetch our users’ data from the API. Notice how we make this call strongly typed:

Everything looks legit. We can use the data retrieved from the API in UsersList component and everything is nicely typed:

The data is even perfectly displayed:

So, what can go wrong here?

The Problem – Typings’ Desynchronization

Let’s say that a backend developer implements a requirement to rename “loyalty points” into “fidelity points”. Easy. (S)he renames LoyaltyPoints property in the C#’s UserViewModel to FidelityPoints.

The new C# model looks as follows:

Nice! The backend dev is a very good programmer, so (s)he even launches the React web application to make sure that everything still works correctly and there are no errors in the dev console:

After a quick look, everything looks awesome. The users list is displayed, there are no errors in the console. Apparently, these test users don’t have any loyalty points assigned – that’s why the empty values in “Loyalty points” column. What’s more, translators will update the column’s translation later. We are good! Let’s go on prod!

I guess you already know what went wrong here. API definition changed, but TypeScript didn’t inform us about that Our UserViewModel still uses the old property name:

However, it still works. When rendering the UsersList, we simply get undefined in place of loyaltyPoints:

In the end, this is all JavaScript there. What’s interesting, the renamed fidelityPoints property is already there at runtime:

but no one cared about it

With the current solution, we will never be informed soon enough about API models changes in our React application. In the best case, we’ll get an undefiend or null error when clicking through the app. However, it’s usually an end user who finds such problems on production. This is definitely not what we want

We can solve this problem by typing API responses with zod. Let’s now see how to do that.

The Solution – zod

Our remedy – zod – is quite a decent npm package with with ~600k weekly downloads. Its GitHub page advertises the library as TypeScript-first schema validation with static type inference.

You can definitely do many things with zod. It can be used together with libraries like react-hook-form to perform complex forms validation. However, in our case, we’ll treat zod as a solution for better typings in TypeScript.

Adding zod to React app

First, let’s install zod into our React application:

npm i zod

First schema definition with zod

With zod, we define our types in a slightly different way. Instead of creating a type or interface directly, we first create a schema. In our case, we can define a UserViewModelSchema using z.object creator function:

Few interesting parts here:

• Line 2: notice how zod helps us to define types like Guid with built-in schemas like uuid()
• Line 8: first, I used AddressViewModelSchema here. This is a custom schema of an AddressViewModel object, which is another type used internally in UserViewModel. You can use such custom schemas in other schemas. Also notice the nullable() call here, which makes the address property nullable

First step done – we have our UserViewModelSchema. But can we use it instead of UserViewModel type? Not really. Schema is used for validation purposes only. We still need the UserViewModel TypeScript’s type.

Inferring type from zod’s schema

Fortunately, zod comes with a handy z.infer function that allows us to infer the type from the schema.

Finally, the userViewModel.ts file looks as follows:

We can use the exported UserViewModel type as previously used type. It’s an equivalent, inferred from UserViewModelSchema.

Validating API responses with zod schema

One last step is to make use of UserViewModelSchema. Let’s modify the getAllUsers function from usersService to validate the data received from the API against our schema:

Notice the usage of z.array. This function call tells zod to validate an array of objects meeting the rules defined by UserViewModelSchema, not a single object.

Now, let’s run our React app and see what happens when we click the “Fetch users” button:

This is awesome! Exactly what we wanted – a schema validation error for API response. Notice how the error message precisely points to the missing (or wrong, in other cases) property. It tells us we expected a number called loyaltyPoints, but instead we received undefined. The reason for this error message is that the loyaltyPoints field is Required in our schema.

After renaming loyaltyPoints to fidelityPoints in UserViewModelSchema and updating the UsersList component accordingly, everything works fine again.

We are now fully typed and prepared for the future, in case an issue with desynchronization of frontend and backend typings happens again

Summary

Today, we’ve seen how typing API responses with zod can help us detect frontend and backend models desynchronization. Schema validation throws errors when the data doesn’t match its expected shape.

Remember that zod is an extended library with many options. I recommend exploring them on your own. An interesting feature we didn’t cover in this article is strict mode, which doesn’t allow additional fields not present in the schema definition when validating the data object.

The open question remains whether to use schema validation on production. One could think that it’s better to not throw any validation errors, because JavaScript may just work. However, I think that throwing an error is always better than silently letting things through. An error lets programmers, automated tests or manual testers to detect the issue before the end user does

You can explore the complete code presented in this article here.

The post Typing API Responses With Zod appeared first on CodeJourney.net.

The title picture of this article shows the end result. If you want to know the solution, keep reading

Context

The context of this need is very simple. I have a unit test in which I want to perform some operations and keep the test running indefinitely afterwards. The use case might be instantiation of an in-memory test server. After that, I want to inform the user (programmer or the one running the test) that the server is up and running. I want to do that before the test finishes. In other words: I want to write the test’s output while it’s still running.

In my case, I was running two .NET Core apps in-memory. The backend server app and the ASP.NET Core web application. In the process, the web app got its IP address assigned dynamically. Meaning that the IP was different with each test run. This particular test was used to run the app in-memory and let the user manually use the application. It means the user must know the IP/URL of the in-memory web app. That’s why I needed to output the dynamic IP address into the NUnit test output

Solution

The solution to write test progress to the console with NUnit is very simple. To do that, use TestContext.Progress.WriteLine(string) method from NUnit.Framework namespace:

And that’s it! I’m publishing this simple solution, because it took me some time to find

I previously tried with TestContext.Out.WriteLine, System.Diagnostics.Trace.WriteLine and System.Console.WriteLine, but all of them output the text after the test finishes.

Finally, you can also run the test from cmd using dotnet test:

Hope it’s useful!

The post Write Test Progress To The Console With NUnit appeared first on CodeJourney.net.

NHibernate.Exceptions.GenericADOException: could not load an entity: 
...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-9042-2B83EEE57B91}'.

The database is not currently available was very interesting to me. I struggled a bit with solving that, so if you want to know how I did it – continue reading

The problem

My .NET 6 app is an Azure App Service, and it uses SQL Server database. Quite standard Azure stuff.

The issue was that when opening the ASP.NET web app after some time of inactivity, there was an HTTP 500 error. When I checked the logs, the full error looked as follows:

NHibernate.Exceptions.GenericADOException: could not load an entity: [MyApp.Infrastructure.DomainObjects.ApplicationUser#37931c5a376748d7a49f215ca30283a2][SQL: SELECT applicatio0_.applicationuser_key as id1_3_0_, applicatio0_1_.UserName as username2_3_0_, applicatio0_1_.NormalizedUserName as normalizedusername3_3_0_, applicatio0_1_.Email as email4_3_0_, applicatio0_1_.NormalizedEmail as normalizedemail5_3_0_, applicatio0_1_.EmailConfirmed as emailconfirmed6_3_0_, applicatio0_1_.PhoneNumber as phonenumber7_3_0_, applicatio0_1_.PhoneNumberConfirmed as phonenumberconfirmed8_3_0_, applicatio0_1_.LockoutEnabled as lockoutenabled9_3_0_, applicatio0_1_.LockoutEnd as lockoutend10_3_0_, applicatio0_1_.AccessFailedCount as accessfailedcount11_3_0_, applicatio0_1_.ConcurrencyStamp as concurrencystamp12_3_0_, applicatio0_1_.PasswordHash as passwordhash13_3_0_, applicatio0_1_.TwoFactorEnabled as twofactorenabled14_3_0_, applicatio0_1_.SecurityStamp as securitystamp15_3_0_ FROM ApplicationUsers applicatio0_ inner join dbo.AspNetUsers applicatio0_1_ on applicatio0_.applicationuser_key=applicatio0_1_.Id WHERE applicatio0_.applicationuser_key=?]
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-2342-2B836E35E891}'.
   at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)

There were two characteristics of this error:

• it always appeared after some time of not using the web app
• I never reproduced it locally

So it must have been something wrong with Azure.

Transient issues in Azure databases

First thing I did, obviously, was checking Azure App Service logs. This is what I found:

The first recommended step got me curious. To reduce the impact of connection issues caused by future reconfiguration, please implement retry logic in your code.

So I started reading. There’s even official Microsoft documentation for that. It basically says that in the cloud environment you’ll find that failed and dropped database connections happen periodically.

I must admit it seemed quite new to me. However, I started digging into that. I used Polly to implement the retry logic in my app. I found few places where there was an NHibernate query for fetching users executed and wrapped it into the retry policy.

Nothing worked. I was still getting the error. Then, after some talks with my coworkers, we found the real reason behind that…

Solution: Azure database tier

When talking about the issue with my teammates, someone mentioned that the databases in Azure are serverless by default.

I logged into the Azure Portal and checked the “Compute + storage” settings my SQL database my app used:

Indeed, the tier selected was “General purpose (Scalable compute and storage options)” with “Serverless” compute tier selected.

I changed it to “Basic (For less demanding workloads)”:

and… it worked All errors saying that the database is not currently available disappeared. I also removed all Polly-related code for retry policies.

A little explanation

Why do serverless databases in Azure behave like that?

I finally found this explanation in the Microsoft documentation:

If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Once the database is resumed, the login must be retried to establish connectivity

That blew my mind! It means that the database is not currently available exception is expected. There’s also another part there:

Database clients with connection retry logic should not need to be modified. For connection retry logic options that are built-in to the SqlClient driver, see configurable retry logic in SqlClient.

Apparently, users of ORMs like Entity Framework should not have to worry about those issues. Unfortunately, NHibernate doesn’t have such built-in transient errors retry logic. That’s why I experienced this particular issue and couldn’t find any straightforward solution online. Simply not many people (if anyone at all? ) experienced this before.

If you want even more details and context, check out this article: SHOULD I USE SERVERLESS FOR ALL MY AZURE SQL DATABASES?

What if I want to use serverless Azure database?

Well… if you really want to use the serverless features of Azure, you might be struggling with NHibernate. As I mentioned, apparently there’s no built-in transient failures retry mechanism in the ORM. There’s one promising solution here. However, currently it’s build for NHibernate 3.3.1.4000, so it doesn’t work with the current version. There’s a Pull Request and an issue opened for upgrading it to the newest version and .NET 6/7. Let’s hope it is done soon.

Otherwise, you can try using Polly as I did initially. However, I didn’t manage to make fully working.

If you have any other idea or solution – let us know in the comments below.

Conclusion

I hope this article saves you some hours of debugging, so you can quickly solve this database is not currently available error in Azure. I wish I found this article on another website few weeks ago

The post How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904) appeared first on CodeJourney.net.

Today I can say that it was the best decision we could make. TypeScript makes working with JavaScript, which is sometimes surprising and quite hard to understand, so much better experience. However, there were some challenges on this journey. If you want to know what issues we met and how we solved them, but also what huge advantages TypeScript gave us – read on

I will not discuss TypeScript itself in this article. This is a pure recap of challenges and the experience I gained when migrating to TypeScript.

Choosing migration strategy

Before starting migrating to TypeScript, we had to choose the best strategy for this process. There were two possibilities we considered: migrating the whole JavaScript codebase to TypeScript at once or switching to TypeScript compiler and migrating part-by-part.

For those who are not familiar with TypeScript – it is a superset of JavaScript which adds typing information to your JS code. It means that every JavaScript code is also a valid TypeScript code. When compiling TypeScript code, TS compiler removes the typing data and outputs readable, vanilla JavaScript code ready to be executed.

Migrating the whole codebase to TypeScript would mean to change all files extensions to TypeScript ones: .js to .ts and .jsx to .tsx. It would also mean that TypeScript compiler starts checking types in those files. This approach is doable, but – depending on the size of your project – can take a long time. During migration the code would be frozen until you fully migrate the project. Also, for TypeScript beginners, it could be a bit frustrating having to type everything at once or use some tricks to tell TypeScript to ignore checking types in many cases (because the type is not known at this stage, or we want to do it later etc.).

Because of that, we decided to migrate part-by-part, having JavaScript and TypeScript files at the same time. It is possible thanks to enabling allowJs TS compiler option. It means that TypeScript will compile both TS and JS files. Such approach allows the coexistence of old JS code with the new TS parts. It also allows moving only chosen parts of the application to TypeScript at the beginning and come back to the others later.

In our web application the biggest JS files have few thousand lines of code. Some of this legacy code still didn’t use React, but Backbone as their framework. We didn’t want to touch these oldest files in the beginning. Instead, we moved few recently written functionalities to TypeScript straightaway and decided to implement everything new in TS as well.

Bright side of migrating to TypeScript

If you are a JavaScript developer, the best advice I can give you is to start using TypeScript In this section I’m describing what positively surprised me since the beginning of starting to use TypeScript.

Types “for free”

As soon as we changed our transpiler from babel-loader to ts-loader, I wanted to know how we can get typing information for already-installed npm packages. It turns out that for 98% of the packages we used there’s already a typing information available as a separate npm package.

In most cases if you have a npm package called abc there’s a typing package available called @types/abc. I explored our package.json and for each package listed there I just executed npm install @types/package-name. 2 or 3 older or not-so-popular packages didn’t have types definitions available, but for the rest we got types for free, without having to type anything ourselves. This was a first, very nice surprise

You can find more information about TypeScript types definition packages, as well as contribute one yourself, here.

All new code is typed

As I wrote before, every new feature we’ve added since the migration is written in TypeScript. Thanks to that, all new code we write is strongly typed. What’s remarkable here is that it required almost no effort. We just switched the compiler to TS (with a small struggle with webpack configuration, about which you can read below) and suddenly got into typed world for every new feature we implement. Quite impressive, isn’t it?

JS-TS friendship

Coexistence and friendship between JavaScript and TypeScript is HUGE. These two creatures are not enemies – they are best friends We’ve already gone through many scenarios when we needed to use something written in TS in a JS file and otherwise. It turns out that all of these scenarios are manageable. Sometimes you need to import something differently (for example using require instead of import), but it’s all possible. We found it super easy to write new features or even add parts of new features to already-existing JS code, writing everything in TypeScript.

We also rewrote some JS files that were used from multiple places in the app to TypeScript. As an example of JS-TS coexistence, I’m presenting below the potential .ts source code you might have. It contains both old, legacy JS code when we used module.exports and prototype to expose various services for data fetching, as well as a brand-new, nicely-exported TypeScript class:

Such code can of course be in separate files, but it only shows how good TS and JS can coexist together. You can keep your old code working, while implementing anything new in TypeScript.

Flexibility in partial migrating to TypeScript

It turns out that choosing to partially move our web project to TypeScript was a great decision. The team wouldn’t be so happy and enthusiastic about TS if we told them to move legacy Backbone code to TypeScript. Instead, we gave them a nice tool which can be used for all new stuff. Also, if someone likes the idea and wants to move already-existing JS file to TS, he or she is welcome to do so.

That’s how we are still migrating our project to TypeScript, without any hustle and frustration

Wisdom of TypeScript

I’m positively surprised by TypeScript almost every day. At some point I get to the issue that seems hard to be solved or quite non-standard. Then I find a solution online and it makes me really impressed about the job the community and Microsoft has been doing around the language.

These are sometimes small, but smart things. Recently we got surprised by keyof, which lets you get names of the allowed properties of your type. Generally the typing system is really advanced and impressive. For some it can be a disadvantage, but I think it gives an enormous flexibility.

This is somehow the JavaScript you-can-do-whatever-you-want philosophy smuggled into TypeScript But in a much smarter way. I’m sure that when you start working with TypeScript you’ll get what I mean by its wisdom

Small effort, huge benefits

Last, but not least, I must admit that migrating to TypeScript was quite an easy and smooth process. The value for the effort is huge. You get a typed world with very little work.

Migrating to TypeScript struggles

During the migration process we met few difficulties. Some of them we managed to solve fully or partially. If you have any better ideas on these things, feel free to let me know in the comments.

Complexity of webpack configuration

When switching to TypeScript we had few issues with webpack configuration. We have used babel-loader before for transpiling JavaScript and initially we wanted to keep it in the TS compilation process. We first tried to keep babel-loader for JS(X) files and use ts-loader for TS(X) files, but it didn’t work – we were getting weird compilation errors.

Then we tried to compile everything using ts-loader and then recompile it again using babel to ensure (as we initially thought would be wise) backwards compatibility. We also couldn’t make it working.

Finally, we decided to compile everything – both JavaScript and TypeScript files – using ts-loader (including React files). It worked, except source code maps. When we tried to debug in Chrome console it seemed the source code is not refreshing properly after rebuilding. Breakpoints were often not hit and the debugging didn’t seem right.

After a bit of struggling we found a solution. We set devtool webpack option to eval-source-map and configured source-map-loader for .js files. Finally, the proper part of webpack config looks as follows:

So far we also haven’t noticed any issues related to backwards compatibility that were theoretically solved by babel. TypeScript compiler does its job very well.

Complicated JS -> TS refactoring

I found out that JS to TS refactoring is not always an easy task. Some things that are allowed by JavaScript are not valid in TypeScript. In most cases it means that something was wrong with your JavaScript code, but we all know how it is with legacy code refactoring

As an example, we had several functions that we added to a String prototype in JavaScript:

Such code becomes invalid in TypeScript:

A non-obvious solution to that issue is to extend String interface by declaring typed functions you want to add:

There are more subtle difficulties like that you can meet while migrating JS code to TypeScript. However, in the end it gives you a possibility to make your codebase better.

Keeping view models in sync

An issue I didn’t think about before migrating to TypeScript was a need to keep frontend and backend view models in sync.

One of the first things you’d like to have in your TypeScript codebase is to have as much typed data as possible. We use .NET and C# as the backend of our application. ASP.NET MVC controllers returned the strongly-typed objects into the previously chaotic and untyped JS world. Now we are strongly-typed with TypeScript, so we’d like all this data typed as well

Here comes the problem. First of all our C# data models which we returned from the controllers were not the best. In most cases we returned a DTO object which contained many properties from which only few were used by JavaScript code. We never saw this problem, because in JS we just dynamically typed properties names we wanted to use. We didn’t see how much of not needed data is sent from ASP controllers to the web browser.

Now with TypeScript we needed to create these objects definitions also in TypeScript. Having a huge DTO object returned from the controller, with another X objects on which this DTO depends, it was a nightmare. It turned out that for a single DTO I had to create 10-15 TypeScript objects just to use 5-10 properties in the frontend code!

That’s the moment when we came to the necessity of creating web view models. The idea is to return a view model from a controller, not the whole DTO object. This view model contains only the data which is needed by TypeScript (frontend).

I think this is nothing new for experienced web developers. However, now comes the question: how do we keep backend (C#) view models in sync with frontend (TypeScript) ones?

Unfortunately, I haven’t found a perfect solution for that. The best method I came up with is… manually keeping these view models in sync.

There’s a C# to TypeScript VS Code extension which allows to paste the copied C# code as its TypeScript equivalent. It makes the job a bit easier. It even has a CLI tool, but it produces a single .ts file from a single .cs file. If you have multiple objects in a single C# file it will produce a single TypeScript file with all these objects. If any of those objects is used in other files (unfortunately we have many of such cases), these dependencies will not be automatically added as imports in the auto-generated .ts files.

However, I don’t find it very problematic for now. As soon as the TS view models are created, we just need to update them as often as we update C# view models. I think this is a very common issue so if you know any better solution here – please share in the comments

Migrating to TypeScript – summary

Migrating to TypeScript has been a very interesting and rewarding process. Compared to vanilla JavaScript, TypeScript lets programmers see many problems. This allows to see how bad our codebase was. We even realized that our server-side C# code was not the best (see the section about view models above). Thanks to introducing TypeScript we improved a lot of our JavaScript and C# code, including its architecture.

I think that TypeScript uses many simple concepts under the hood and it makes a lot of things possible (see keyof or unknown). In many cases TypeScript lets you do something, but doesn’t force you to do it. That’s the beauty of this typed JavaScript world

The post Is It Worth Migrating to TypeScript? appeared first on CodeJourney.net.

How will this possibility change the way we write C#? Why is it being introduced? I’ll try to address these questions today

Interfaces today

As we all know from the current version of C#, interfaces allow to define a kind of contract, which must be respected by a class implementing it. Today interfaces can only contain definitions of methods (with no body). These methods are then actually implemented by concrete classes. If a class doesn’t implement all of its interface’s methods, compiler produces an error.

What’s problematic in this approach? Assuming that you have the following interface and class(es) implementing it:

With time, you may want to extend IDeveloper interface by adding a new method, for instance:

Now you have a problem, because the new method must be implemented in all places where the interface was used. Compiler gives you an error as long as it’s not done:

If your interface is used in many places, also by another teams or developers (which is often the case in reality), this is a breaking change

It may be really painful, depending on how extensively your interface is used. In any case, all classes based on the IDeveloper interface must implement the new LearnNewLanguage(string language) method. Only then the code compiles.

One of the reasons for introducing into C# default interface methods is to avoid such breaking changes scenarios

Default Interface Methods

As we can read in the feature’s design notes, an inspiration for it is a similar concept already alive in Java – Default Methods.

The main idea of this new C# feature is a possibility to provide a default implementation of an interface’s method.

Realization in C# 8.0

In our example using C# 8.0 we’ll be able to implement it as follows:

In that case, our class implementing the IDeveloper interface can legally not implement this new method and there will be no compilation error:

Notice that it only works when BackendDev is contextually treated as IDeveloper. It means that a class doesn’t inherit members from the interfaces it implements:

What about multiple inheritance?

As some of you probably realized, this new feature exposes C# to a multiple inheritance problem (also known as Diamond of Death). So far C# didn’t have this issue, because we can only inherit from a single class. We can implement multiple interfaces, but so far the interfaces couldn’t provide methods’ implementation. Because of that, there was no Diamond of Death possible. Soon it’s gonna change

Diamond of Death in C# 8

In case of C# default interface methods we may illustrate this issue with the following code:

Please note that the syntax or places in which compiler generates errors may still change in the final feature’s version.

To better illustrate this Diamond of Death example, take a look at the following diagram:

The question is: which method should be called in such case?

Solution: most specific override rule

C# 8.0 will solve this issue by introducing the most specific override rule. It means that in our case illustrated above, the compiler will issue an error and won’t let us do this.

To avoid this ambiguity, we’ll be forced to implement or override LearnNewLanguage(string language) in IFullStackDev interface. Only then it will be considered the most specific version of the method in the interfaces hierarchy we have. It will then be used when calling the method on objects contextually treated as instances of IFullStackDev. We could also implement it directly in the Dev class and use the class (not interface) type. It would then call the most specific method from the class. This way multiple inheritance issue will be eliminated.

Compiler for the rescue

There are a lot of other potential ambiguity scenarios that may take place after introducing into C# default interface methods. You can check all of them with potential solutions well-discussed on GitHub.

The general assumption is that all code which may lead to issues related to default interface methods implementations is detected by the compiler. In effect, we should get appropriate errors when compiling the source code. That way, programmer can fix all potential conflicts directly when these arise.

What about .NET Framework?

What’s interesting with default interface methods is that it requres changes in the runtime. According to current assumptions, it means that this feature will not work with .NET Framework! Only CoreCLR and Mono stack runtimes are going to receive these new updates.

Summary

As the motivation for introducing into C# default interface methods the language team members mention possibility to interact with some Android and iOS APIs, which already support such feature. They also claim that C# will get the traits programming language feature with default interface methods.

In my opinion this is the most controversial from all C# 8.0 new features. It completely changes something which was obviousness for the developers for years. Probably we’ll see less breaking changes issues when the interfaces are extended, but looking on the list of issues and edge cases it produces… Maybe assuming it already works in a similar way in Java we should just accept it?

Another interesting, .NET-specific aspect is that this feature will not work with .NET Framework. It’s probably the very first moment when the difference in pace between .NET Core and Framework is so explicit.

I’m also very curious about the performance implications of default interface methods. I’ll for sure be following this issue on GitHub to see how it evolves

What do you think? Is it a good idea to introduce default interface methods into C#?

The post C# 8: Default Interface Methods Implementation appeared first on CodeJourney.net.

Let’s see how this tiny feature is supposed to make our life easier

Goal of slicing

The main purpose of introducing slicing into the language is to make working with arrays and strings easier.

Currently, when you want to retrieve a fragment of an array (X elements from the array, located for instance in its middle), you can use LINQ, i.e. combination of Take and Skip methods. You can also create some extension method to provide kind of slicing.

To illustrate the current way, using LINQ to retrieve only 2nd, 3rd and 4th elements of an array looks as follows:

C# community and designers decided it’s not convenient enough, so are now adding to C# 8 indexes and ranges (in order to provide slicing)

Index

C# 8.0 comes along with a new object – System.Index. It’s a structure internally and looks as follows:

What’s interesting here, is that the constructor takes the value of the index and boolean flag fromEnd. Let’s see how we can use it in practice:

While the first printed value is nothing special, as you can see we can now use the hat operator (^) in order to index from the end. The following also works:

It means that the ^ operator is a syntactic sugar for Index. I allowed myself to check the IL produced:

As we suspected – an instance of Index is created, passing 3 as value and true as fromEnd (see the constructor parameters above).

Range

Another concept which uses Indexes is a new structural data type – System.Range:

As you can see, it really uses Indexes. We can even try creating it on our own:

This doesn’t really make extracting data from the arrays better than Skip-Take LINQ, does it?

Fortunately, there’s another friendly C# language element introduced called range expression. It can be written as x..y and used directly for indexing:

This looks much better! Let’s see how C# compiler translated our 2 lines of code by looking at the pseudo-C# IL produced:

Even though we could achieve the same with much less LINQ, C# compiler does a lot of stuff for us, keeping our code simpler to grasp.

Ranges in strings

All these operations apply also to strings:

Ranges in foreach loop

Next interesting usage is in the foreach loop:

Summary

I see these “little” C# 8 indexes and ranges as another helpful feature. It’s less breaking and controversial than nullable reference types, still making us write less C# code in the future.

If you’d like to dig the feature even more, I encourage you to read the discussions about it on GitHub, which I always find very interesting

Developers, what do you think about C# 8 indexes and ranges?

The post C# 8: Slicing with Indexes and Ranges appeared first on CodeJourney.net.

Learn about building C# 8.0

C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.

What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.

I will publish a separate post regarding each feature which I find particularly interesting

Nullable reference types

First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.

A bit of history – NullReferenceException

Consider the following code:

Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:

In this case, jsDev.LastName is of course set to null.

NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?

New world – #nullable enable

For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.

In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.

Notice what happens when we enable it in our example:

We’re still able to compile, but this nice warning is displayed As soon as we initialize LastName property in the constructor, the warning disappears:

If you try to cheat, it still works like a charm :

But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:

Nonetheless, in such case, the compiler still takes care of us:

The final fix is quite obvious – we need to check for null first:

At this stage all warnings finally disappear. You can find the finished source code here.

Nullable reference types in IL

The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:

It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).

Summary

I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.

What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments!

The post C# 8: Nullable Reference Types appeared first on CodeJourney.net.

These features of JavaScript language are the most striking differences compared to C# ecosystem. If you’re about to learn JavaScript, sooner or later you’ll also have to deal with them.

Before we begin, one disclaimer: the goal of this post isn’t stating which language is better or worse. JavaScript and C# are different programming languages and their use cases are also completely different. One is better for some usages, while the other is better for others. The list is my and other readers’ subjective one and you don’t need to agree with all points. I’m myself a C# developer on my JavaScript learning journey, so I’d like to help you grasping these confusing concepts

1. Dynamic Typing

Obviously, the first difference JavaScript newbie notices is that the language is dynamically-typed. It means that the types (of variables, functions, actually of almost everything) are checked at runtime, not at compile time like in C# or Java.

Because of that, there’s not much difference in defining variables and assigning them data of various data types:

JavaScript’s variables are not associated with any particular data type. That’s why it’s completely legit to write something like that:

Because JavaScript is dynamically-typed, issues with types are detected at runtime (e.g. error is thrown as soon as you try to use a variable in a context which expects another data type), not during compilation time as it would be in C# or Java.

If you have some experience with statically-typed languages, you may now feel how much confusion and troubles dynamic typing can bring. At least at the beginning.

2. Implicit types coercion

JavaScript has one more interesting feature – types coercion. Even though this term’s name sounds a bit weird , it’s quite simple: types coercion happens when a value of one type is converted to another one.

3. null and undefined

In JavaScript there are two values which represent kind of unassigned variables: undefined and null. What’s the difference between them? The snippet below clarifies:

5. Hoisting

In JavaScript you can legally write such a code:

As you can notice, name variable is used before it’s declared 2 lines below. This is maybe not that weird, as in JS we can even declare variables without the var keyword, but we can do the same with functions:

So here we call the function before declaring it. Why does this work?

This works thanks to hoisting. It’s a compile-time mechanism which “moves” all variables and functions declarations to the top of our JavaScript code. In fact, during the execution of above-listed code, JavaScript engine processes variables and functions declarations before executing any other code.

It however applies only to declarations, not to assignments:

6. Lexical scoping and this keyword

To create a scope (space in which the variables defined in it are accessible) in JS, we need to create a new function. Variable defined in a function is not accessible outside this function:

It means that other blocks like the ones associated with if statement don’t introduce a new scope:

If a variable is defined outside of any function, it’s assigned to a global scope.

However, in JavaScript we also have something called lexical scoping. It basically makes functions declared within another functions having access to the parent function’s scope, as the following example presents:

Forming such “hierarchy” of functions is also referred to as scope chain. You should remember that it refers to the order in which functions are lexically written, not in which they are called:

As you can see above, as soon as we call a(), which then calls b(), within which we define variable x and then call function c(), inside of function c() we don’t have access to x variable (x is not defined). Why does it happen even though function b() in which x variable is declared called function c()? Because function c() is not lexically written as the child function of b(). Parent scope for function c() is always the global scope.

7. this keyword

All these scoping rules examined above somehow lead to another confusing concept with this keyword. As soon as we define a method on some object and try to print the this keyword in this object’s method, the result seems reasonable:

However, if we just define an inner function in our method and try to print this keyword inside it, weird stuff happens:

As you can see, the this keyword in the innerFunc() function doesn’t point to the blogger object anymore. Instead it points to a Window object, which represents the browser’s window (this used in the global scope points to it).

This happens because in a regular function the this keyword points to the global object (Window object in our case). innerFunc() is here considered as a regular function, not as an object’s method. This behavior may be confusing and is often a subject of dispute in JavaScript community.

8. sort() function

You’re a newbie JS developer and you’d like to sort an array of numbers. You found a sort() method on the array, so why not to use it? You write such code:

What do you expect to be logged in the console? Let’s see:

(5) [-5, 15, 20, 40, 7]

Nice! What happens here? 7 is greater than 40? Well, yes It works as expected, because the sort() function sorts array’s elements as strings and alphabetically. Therefore, if our array contains numbers, the final order depends on the Unicode representations values of each number.

Fortunately, there are ways to use sort() function correctly for numbers, but this functionality is still confusing for new JavaScript developers.

9. Prototypes

Every object in JavaScript has a __proto__ property. We can access it directly on our object or by using Object.getPrototypeOf() method. In both cases, having created an empty object and printing its prototype to the console like that:

produces the same output:

On the top of objects hierarchy, there’s Object. Because of that, our x object is an instance of Object. That’s why the prototype of our x object is actually the Object.prototype, which contains some common methods we can use (like toString()).

If we try to access Object.prototype.__proto__, we’ll see that is contains null.

Prototypes in JavaScript are mainly used to provide some connection between two or more objects (like exposing some common methods).

All this “hierarchy” of prototypes is used to search for fields and methods of objects: the JS engine first searches in the object itself and if it cannot find particular property, it looks in this object’s prototype, and then in its prototype until it finds the first matching occurrence. As soon as it reaches null in the Object.prototype.__proto__ it means that the prototypes chain has ended and undefined is returned.

This kind of prototype inheritance is different than class inheritance, so it’s often confusing for developers willing to learn JavaScript. Actually, I could write a separate post on this, so if you’re interested you can read more for instance here.

10. IIFE

IIFE is an acronym for Immediately-Invoked Function Expression. So what is it and how can it be useful?

Going straight into the code, IIFE can be written as follows:

As a result of executing such script in a web browser, we’ll see the following console output:

Hey!

How does it work? We neither declared a function’s name nor called it, right? Actually, we did

There are two unusual parts of IIFE implementation: outer parentheses in which we “wrapped” our function and “empty” parentheses together at its end.

Let’s start by “wrapping parentheses”:

Why do we declare them? Because if you don’t, JavaScript parser will give you an error:

script.js:1 Uncaught SyntaxError: Unexpected token (

In such case it thinks that we’re writing a function declaration and we forgot about providing the function’s name after the function keyword. Wrapping this into parentheses (…..) tells the parser that we’re declaring a function expression, not a declaration. After doing this, there are no errors anymore.

The second important part is the “empty” parentheses () just after the function expression:

As you know, () allows to call the function. That’s exactly what we do here here – our function is immediately executed.

Why would we need such construct as IIFE? Developers say that it doesn’t “pollute” the global scope. In effect, we are not leaving the function somewhere after being executed, so no one else can call it accidentally from another place. What’s more, IIFE is even considered a design pattern.

You should know that such construct exists even only to know what it does seeing it in someone else’s code. If you want to know more about its use cases, I recommend reading this article.

Summary

In this post we’ve gone through some of the most shocking features of JavaScript language for C# developers. Most of them are confusing for programmers coming from statically-typed and class-based languages and can bring a lot of issues in the beginning of their JavaScript journey.

Just remember that these are the JavaScript’s language features, not its issues or bugs. That’s just how it is, but it cannot be said that JavaScript is worse or better than other languages like Java or C#.

The list for sure is not exhaustive, so if you have anything to add or correct don’t hesitate to leave a comment!

For the end, I’ll just leave you with the following meme-but-true (thanks Youenn ):

Stay tuned!

The post 10 Most Shocking JavaScript Features for C# Developers appeared first on CodeJourney.net.

By execution model I mean a process of having a .NET Framework application actually executed on the machine (CPU), starting from having its source code written. It contains all steps and actions necessary to happen in order to transform source code (like C#) into machine (assembly) code and execute it.

.NET languages standardization

As we all know, .NET is just an execution platform. There are, however, a lot of programming languages which allow us to write code which can then be executed by the platform-specific (not language-specific!) CLR. In order to give programming languages’ creators a set of rules which their language and its compiler must meet to be .NET-compliant, Microsoft defined a Common Language Infrastructure (CLI, also referred to as MSIL in the old days ) which is also standardized by ISO and ECMA.

The main goal of it is to define how the source code should be compiled to the Common Intermediate Language (CIL). As we already know, the CIL should have a standardized format, because it’s then JIT-compiled to a platform-specific assembly code. Some of the most common implementations of CLI are .NET Framework, .NET Core and Mono. I recommend you to check Matt Warren’s article on .NET Runtimes history as well

Common Language Infrastructure implies also some other aspects of the programming language and its compiler, including Common Type System, language-agnostic metadata and Common Language Specification. You can read more about it for instance here.

This all allows us to use various programming languages, like C#, VB.NET, F# or JScript .NET to develop .NET applications. Anyone can still implement their own own .NET language – it “just” needs to conform to the standards.

There’s also another term introduced somewhat around .NET Core – .NET Standard. Its purpose is to allow code sharing between various .NET implementations. It actually defines a set of APIs that each .NET platform should implement. More details here.

This whole standardization makes us arriving to the .NET applications execution model, which is how every standards-compliant CLR application is executed.

.NET execution model

Independently of the language of choice, .NET application’s execution model can be described as the following 4-steps process:

1. Writing source code in a programming language of choice, including the usage of its compiler
2. Compiling source code to Common Intermediate Language (CIL)
3. Compiling CIL into native code – details of this step in the previous post
4. Execution of the native code.

These steps are well-resented on the schema below and then described in details in the next sections.

Writing source code in a programming language of choice

As mentioned before, .NET applications can be implemented using any language of choice, which is compliant with CLI. Another important part is a compiler – it defines a general syntax of the language, kinds of data types that can be used by a programmer etc. For instance, current open-source compiler for C# and Visual Basic is Roslyn.

In the end, role of the compiler is to transform the source code to its CIL equivalent.

The simplest possible complete application written in C# can look as follows:

Compiling source code to CIL

After the source code is written, it must be compiled to CIL, which is an intermediate language understood by the CLR. On this level, the whole execution process becomes language-agnostic, which means that as soon as the code is compiled to CIL it is executed by the CLR and programming language’s features (e.g. its compiler) don’t play any more role.

CIL code looks more like assembly code, however containing some specific instructions. It’s still far more readable than native code. Apart from the direct transcript of source code, CIL contains metadata about the DLL/EXE assembly file.

The C# fragment presented in the previous section compiled to CIL by Roslyn looks as follows:

A bit more than the original source code, isn’t it?

Firstly there is a metadata instructions section which contains information about the assembly, execution framework’s version, types used in the code and external references. Next there’s the actual CIL code (equivalent to C# code presented above) listed.

Compiling CIL into native code

We’ve already covered this step in details in the previous post about Just-In-Time compilation, which is just a bit more fancy name of this process Now you can see how and where it fits into .NET application’s execution model.

Normal JIT compilation

By default, JIT compilation is done in the place where “Normal JIT Compiler” is drawn on the schema below:

IL instructions of a particular block of code, in the example diagram of a method Foo(), are JIT-compiled when the block is to be used for the first time. Then, this JIT-compiled code is stored as the JIT-ed equivalent of Foo() method’s code in the memory cache. Such native code is then executed and if the same block of code needs to be called again in the future, it will not be re-JIT-compiled, but instead the native code will be taken from the memory cache and executed again.

There’s a possibility to skip adding the native code into memory cache for future executions and it’s referred to as “Econo JIT Compilation”, however it’s not widely used and probably obsolete since few versions of .NET, so we won’t examine it here.

Pre-JIT compilation

The schema presented above changes a bit as soon as we want to use so called Pre-JIT compilation. We mentioned it already and we know that one of the techniques to allow pre-JIT (or ahead-of-time) compilation is using Native Image Generator (ngen.exe) which allows to transform CIL assemblies into native code files and to store them as a file on the disk (in the Native Image Cache). It allows to natively compile the whole assemblies – it doesn’t allow to compile only single methods as JIT compiler does.

Refer to the new version of the schema presented below to see how the process changes with NGen.

Normal and ahead-of-time CIL compilation modes provide different cons and pros, including:

• NGen delivers faster start-up time, especially in large applications used by many users in the same time, but requires more disk space and memory to store both the CIL and pre-compiled images,
• JIT compilation at runtime can deliver faster code, because it targets the current platform of execution; NGen produces the native images with instructions that can be executed on all possible platforms, meaning it must use the oldest from currently used instructions sets to be backwards-compatible,
• JIT is able to dynamically re-compile the code for a better performance depending on the execution conditions (e.g. by detecting a hot path in the executed code).

Choosing one of the modes depends on your use case.

Execution of the native code

Finally, the code blocks are run by the CLR, which asks CPU to execute compiled instructions sets. If you’re interested in how CPU exactly works and executes the instructions, I recommend you watching this YT video.

Summary

We’ve seen today how the .NET applications are executed step-by-step, starting from source code (like C#) up to being actually executed by the processor.

I also encourage you to read – if you haven’t already – all the previous posts in the .NET Internals series. Just click here to see them all

Let me know if you have any doubts or thoughts, I’m always open to your comments and opinions Especially the constructive ones pointing out some parts I omitted or didn’t describe precisely enough.

I hope it helped you learn something new

The post [.NET Internals 10] Application execution model appeared first on CodeJourney.net.

What makes managed applications portable?

Intermediate Language (IL)

Viewing MSIL

Just-In-Time (JIT) compilation

How Toyota brought us JIT?

Let’s start by some historical background In the early 1960s, Japanese engineers at Toyota had to reorganize their warehouse management, because they had very high storage costs – delivery of the parts from suppliers took a lot of time, because they ordered a lot in advance. Every delivery had to be handled by someone, so they needed a lot of employees. Ordered parts were stored in the warehouses for a long time, required a lot or storage space and maintenance.

JIT compiler

Following Toyota’s success , CLR creators introduced a just-in-time (JIT) compiler into the framework. Its role is to compile intermediate language code into assembly language according to hardware and operating system’s characteristics (depending on the machine on which the code is being JIT-compiled). Unlike unmanaged languages, in which the source code is compiled into machine language prior to program’s execution, IL is (by default) compiled to CPU instructions at runtime. That’s how .NET engineers made the machine code delivered on time to the CPU.

JIT compiler is a part of CLR (similarly to garbage collector). To make things simple, it can be said that JIT compiles a particular method’s source code as soon as this method is called for the first time. Of course, it takes into account the hardware, e.g. the CPU type and its instructions set to produce correct assembly code. Such machine code is then saved in the cache and re-used every time the same method is called again within the same application’s execution. It means that the parts of the code which are not used (called) during the program’s execution may not be JIT-compiled at all.

Just-In-Time compilation is actually a combination of two approaches: ahead-of-time compilation and interpretation, mixing advantages and disadvantages of both. However, compiling IL code into assembly one at runtime allows for several interesting features like dynamic typing (ability to retrieve the actual object’s type at program’s execution). That’s why JIT compilation is often treated as a form of dynamic compilation.

Another advantage of having JIT compilation is that the source code we write is “further from the hardware”, so it can be made more readable and human-friendly, whereas the metal-touching stuff is “hidden” in the IL (kudos to MSIL developers!)

Can we still compile ahead-of-time?

Summary

In one of the next posts we’ll dig into application execution model in .NET Framework, where we’ll see when and how exactly the JIT compilation process fits into the whole C#->CPU journey

so if you have your own opinion on JIT or any other remarks, don’t bother and share it in the comments!

The post [.NET Internals 09] Just-In-Time (JIT) compilation appeared first on CodeJourney.net.

(De)allocating objects on LOH

As we know from the second post, during allocating the memory only objects of size greater than 85,000 bytes are placed on LOH. There are also some exceptions, like arrays of double which are put on LOH (in 32-bit architectures only) as soon as they reach 1000 (or more) elements (not something around 10626 elements as could be expected). This is quite important to know to be aware what kind of objects have impact on heap fragmentation (more details below).

So we know when the objects are allocated on LOH, but when are they deallocated?

LOH is collected in the same time as the generation 2 collection occurs. It can be triggered if memory threshold for either gen 2 or LOH is exceeded. Conditions for garbage collection can be found in this post.

That’s why keeping large LOH may affect the GC’s – and the whole application’s – performance.

Garbage collection on LOH

LOH fragmentation

The reason why Large Object Heap is not compacted (by default) is because it’s used to store big objects (>85,000 bytes). Copying such amounts of data would seriously incur the performance of garbage collection process.

Anyway, memory of objects allocated on the LOH is reclaimed so it may eventually become fragmented:

We’ll see below how, but .NET keeps track of “Free space” memory blocks to know which chunks are available for new allocations on LOH. When allocating it looks for a block large enough to store the whole object.

However, imagine that there are 2 free space blocks next to each other. Both were marked free, but they represented different objects (maybe they were next to each other on the heap because one referenced the other). What do you think GC will do? Will it treat them as two separate free memory blocks, making less chances for the next allocated object to fit into one of them?

Fortunately not. GC has an optimization introduced which makes such adjacent free memory chunks “merged” together:

How does GC do it? Let’s see in more details.

Free memory representation on LOH

Instead of compacting Large Object Heap, garbage collector keeps the address ranges of not used large objects in a Free Space Table:

As you can see on the figure above, as soon as gen 2 collection run, address ranges of two unused objects were just added to the Free Space Table.

Now you can see that “merging” two adjacent free memory chunks is just a simple addition operation (or modification of one number in the table).

Allocating memory on LOH

As soon as a new large (>85,000 bytes or applicable array) object is to be allocated on the managed heap, GC looks for a single “Free Space” block to hold it. However, it’s rather unlikely that the particular object’s size will fit into one of the free memory chunks. In that case, a new object will be allocated on the top of the heap (just after ‘Object D’ on the figure above).

It may happen that the memory obtained from the operating system for LOH is already used (read here for more info about memory). Garbage collector then asks the operating system for more memory segments to be acquired for LOH. If it fails, gen 2 collection is triggered hoping that some memory blocks will be freed and then the allocation will be possible.

Let’s now think about it for a while. We said previously that LOH collection triggers gen 2 collection. So trying to clean-up the Large Object Heap every time an allocation on it is made would be a potential performance killer.

How does GC solve this issue? Well, in fact, after a lot of optimizations introduced to LOH management in .NET 4.5, the GC takes the following actions in order to make a new allocation of a large object:

• firstly, the GC tries to allocate new objects into one of the free space “holes” on the LOH (it’s quite simple to calculate whether any chunk is large enough to store the object knowing ranges of free space blocks from the Free Space Table).
• if the above fails – garbage collector prefers to allocate new large objects at the end of the heap. Even though it may involve asking the OS for more memory segments, it’s been found to be easier and less consuming operation than performing full GC hoping to free some memory chunks on the LOH first.
• only if the above fails (LOH cannot be “extended”) – GC triggers gen 2 collection hoping to free some additional space that could be used for a new allocation.

What’s worth noticing is that this actions order seems to be good for performance, but can sometimes be a reason of memory fragmentation.

Manual LOH compaction

As you should already know from the previous article, LOH can be compacted programmatically, by setting the GCSettings.LargeObjectHeapCompactionMode property. The simplest way to force LOH compaction is as the following snippet presents:

There might be some niche cases in which LOH compaction may be useful. More details and discussions can be found for example here.

Best practices working with LOH objects

We can try to simply design our applications to use the less possible number of large objects, but let’s not exaggerate. We are living in a world where 8GBs of 2133MHz RAM costs sometimes less than 100$, so the memory is generally cheap

In principle, the rule seems to be simple: large objects we allocate should be reused (e.g. cached) as much as possible.

We should just keep in mind that allocation of large objects can be costly, because of a need to perform gen 2 collection in some cases before the object is allocated.

An example of potentially problematic large object can be a ViewState used in ASP.NET applications, size of which can easily exceed 85K. There are some good articles explaining how to not stupidly incur ASP.NET app’s performance using it, for instance this one.

There are also a lot of tools which can be used to measure the memory state and performance of our applications (also its internal mechanisms like garbage collection, heaps compaction etc.) which we’ll surely cover in one of the next posts within the series

Summary

Today we examined – previously a bit forgotten – Large Object Heap. We saw how the information about free memory blocks on it is stored by .NET Framework and how new objects are allocated on it.

I think it’s one of the next internal concepts of .NET worth knowing and understanding, even though in the common scenarios and business applications you probably won’t get into troubles with LOH. However, it may be practical and useful to know when working with some more memory-demanding applications like games.

I hope this post clarifies some LOH topics for you.

Let me know if there are any topics you’d be interested in reading about. I’m here to provide some value to you, so I’m open for your criticism and suggestions

Stay tuned!

The post [.NET Internals 08] What about Large Object Heap (LOH)? appeared first on CodeJourney.net.

Heaps generations

As we know from this post, heaps used by .NET process to allocate reference objects are allocated on different kinds of heaps. In the previous article we also got to know that only Small Object Heap (SOH) is the subject of compaction process. Large Object Heap (LOH) is not compacted because of the performance reasons.

This is however not the only optimization introduced by GC contributors into Small Object Heap. SOH in .NET is also divided into 3 generations:

• Generation 0 – containing newly created objects, which did not have any collection performed on them so far,
• Generation 1 – storing objects that survived a single garbage collection (were not reclaimed during it because of still being in use),
• Generation 2 – keeping long-lived objects that survived two or more GC cycles.

LOH is not divided into generations. More details on LOH management in the article linked just before the “Summary” section below.

Thanks to such a division of managed heap, the actual collection is performed not on the whole heap, but only on one of the generations, where:

to perform a collection on generation X == to collect objects on generation X and all its younger generations

That’s why a generation 2 collection is knows as a full garbage collection. During this process objects present on all heaps (on all generations: gen 0, gen 1 and gen 2) are examined and reclaimed. Obviously, this collection is also the most costly one.

Collection survivors

In that place we should introduce a term collection survivor. It can be defined as an object which survives the collection (is not collected during GC collection cycle as it’s still referenced by something).

Knowing that, the following “promotion rules” can be defined:

• object survives generation 0 collection => object is promoted to generation 1,
• object survives generation 1 collection => object is promoted to generation 2,
• object survives generation 2 collection => object stays in generation 2.

Collection thresholds in generations

In the 5th post in the series, it was mentioned that one of the conditions on which the garbage collection can be triggered is when “the memory used by the objects on the managed heap exceeds some defined threshold”. In fact, this is not a single threshold, but several thresholds. More precisely, there’s a separate one per generation. As soon as size of all objects in a particular generation exceeds threshold’s value, the collection is started.

In the beginning, the thresholds’ values for each generation are initialized to the following values:

• gen 0: ~256K,
• gen 1: ~2MBs,
• gen 2: ~10MBs.

Nonetheless, these are only initial values and are adjusted by the GC at runtime. One of the conditions to increase a particular threshold’s value is then the survival rate in a generation is high (more objects from particular generation are either promoted to the next one or stay in generation 2), which makes the GC cycles to run less frequently (the condition of exceeding the threshold is not met that often).

This approach seems reasonable, as the main goal of GC is to collect as many objects as possible and reclaim their memory, not to “waste time” only to get to know that most of the objects are still in use.

In general, CLR tries to find a balance between two factors:

• not letting application’s working memory set to get too big,
• not allowing GC to take too much time.

Structure of generational heap

The diagram below presents how SOH actually looks like being divided into above-described 3 generations:

As can be noticed, the next object pointer (you can read more about it in this post) refers to the place after the last object in generation 0. That’s how it happens that newly created objects are always allocated in generation 0.

Generational GC cycle

The following schema very clearly presents how the full generational collection looks like (click to enlarge to see it clearly):

The first step is generation 0 collection. You can notice that objects H and D are not referenced by anything, so after the first cycle on gen 0 is performed, these objects are reclaimed and not promoted to gen 1. The same happens with object F, which is not being referenced to anymore when the collection on generation 1 is performed – that’s why it’s reclaimed during this step and not promoted to generation 2. In the end of the full GC cycle, only still-referenced objects stay on generation 2.

What’s also important to notice is that after each collection generation 0 becomes empty (contains no objects). Generation 1 may still contain objects promoted from generation 0 and generation 2 may contain long-lived objects.

Why is static data harmful for GC?

Having the knowledge presented in this post, we can deduce that the more objects are stored on a generation the longer collection process lasts. What we should also already be able to see is that generation 2 contains long-lived objects which are mostly static or global objects that survive garbage collection cycles (as there’s always a “live” reference to them in the application).

Of course, there are some reasons why static data can be justified (e.g. server-side apps storing some context), but normally using static data should be avoided as much as possible and reasonable. I think you already know why – it simply incurs the application’s performance by making garbage collector’s work harder and longer.

Cross-generation references

There’s also one very interesting issue in having the managed heap divided into generations. Can you imagine the case, when an object is already promoted to gen 2, but one of its reference-typed properties has just been initialized in gen 0? Consider the following code:

Let’s assume that an instance of GuyFromGen2 has already been created long time ago and it’s already promoted to generation 2. At this moment someone calls CreateYoungObject() method, which initializes _youngObject variable. This makes the “parent” instance of GuyFromGen2 holding a reference to its instance object located in gen 0. 

When there’s a generation 0 collection triggered (which, as we said, examines only objects in generation 0) at this exact moment, it would find _youngObject allocated on the heap having no gen 0 references to it (as it doesn’t check gen 2 references during gen 0 collection) so it would assume the object not being used and reclaim its memory.

Fortunately, .NET has a solution for this issue – card table data structure.

Card table data structure

Card table is used by .NET’s memory management system to store information about objects from older generation (gen 2 in that case) that reference younger objects (from gen 0 or gen 1). The execution engine adds an entry into card table as soon as any reference to gen 0 or gen 1 object is created “inside” gen 2 object.

For performance optimization reasons the card table stores this information per “bit”, which represents 128 bytes (or 256 bytes in 64-bit architectures) of managed memory. That’s how the card table can be imagined:

Then, as soon as gen 0 or gen 1 collection takes place, apart from examining references only from the particular generation’s roots, GC also checks which memory ranges have their bits set to 1, finds out which objects are allocated within these memory ranges and treats them as potential GC roots (analyzing what these objects reference).

What’s more, as Konrad pointed out in his comment, because of write barrier optimization the whole bytes (8-bit chunks, not only single bits as presented on the figure above) are marked as potential roots sources. So in fact, such cross-generations reference can mark up to 2048 bytes (for 64-bit architectures: 256 bytes x 8 = 2048 bytes) memory chunk as a potential GC roots source.

Every referenced object found this way is added to the list of objects still in use (if you still don’t know what are GC roots and still in use objects list, read the previous post now).

but… what about LOH?

If you’re curious about Large Object Heap (LOH) in-depth memory organization, I recommend you reading this article by Maoni Stephens. I can just mention that LOH has its own memory threshold which can be exceeded and it also triggers Gen 2 collection – from GC point-of-view, collection of objects allocated on LOH happens only during Gen 2 collection.

Summary

We went through the concept of having SOH managed heap divided into 3 generations. By understanding how objects are promoted between generations and the implications of being a long-lived object we saw the potential harmful impact of static data on our application’s performance.

Another interesting thing we pointed out was the card table data structure used to solve cross-generations references issue.

Next week we’ll see more on unmanaged resources and objects’ finalization.

Stay tuned!

The post [.NET Internals 06] Generational garbage collection appeared first on CodeJourney.net.

Finding objects to be garbage-collected

As we already know, .NET doesn’t allow developers to directly allocate the objects on the heap. Instead, the only thing the programmer needs to do is to use the new keyword – framework takes care of all the rest (placing the object on the proper heap, initializing it etc.). After that, you can simply forget about your object, because it is released (collected) automatically by the garbage collector as soon as it’s not needed anymore. But how does the GC know which objects it can collect?

In principle, all the garbage collector does is looking for the allocated objects which aren’t referenced by anything, which means that such objects are no longer needed. This makes such objects ready to be collected (their memory can be released – marked as being possible to be used again).

There are several sources of references to objects allocated on the heap:

• stack (as we know from the 2nd post),
• global or static reference variables,
• CPU registers,
• interop references (.NET objects used in COM/API calls),
• objects finalization references.

GC roots tree

All above-listed sources are called GC roots (also referred to as root references). As objects referenced from any of the roots can reference another objects (for example a customer may reference its orders collection), all these nested references are represented as a tree (graph) for every .NET application. Such references tree may look as follows:

As you can see, GC root is present on the stack, pointing to Customer reference object. It contains an ArrayList collection of orders, which is referenced by Customer object. The collection itself also contains references to its elements, so the tree grows up.

Each root contains either a reference (address) to some object or null value.

Unreachable (not used) objects

The GC roots tree described above is used by garbage collector to know which objects are no longer needed. As we see, the graph contains all objects that are still in use (are referenced by something else).

GC uses this information the other way around –  generally the GC classifies all objects that are not reachable from any root (not present in the graph) as garbage. Such objects are then collected (the memory allocated for them is released) by the GC during its collection cycles, which will be described in details in the next posts in the series.

Memory releasing (garbage collection)

As mentioned, garbage collection is a process executed in cycles, which will be covered in the later articles, but the process itself contains two main steps:

1. Marking phase – finding which objects are still in use,
2. Collection – actual collection process of not-anymore-used objects (including SOH compaction).

Let’s see both phases in details.

Marking phase

When garbage collector runs its memory releasing process (referred to as ‘collection’), it needs to know which objects on the heap are still in use by the application – obviously, such objects cannot be collected.

In order to obtain this information, GC goes through the whole root references tree and for each GC root moves along all its reference tree (all objects that are referenced from the particular root) in order to mark each object in this tree as “still in use”. That’s why this integrated part of garbage collection process is called marking phase.

Marking is a recursive operation, because as we said before, roots reference some object, which references another object, which references another object…

so in order to make sure that every object in use is added to the “still in use” list (if it’s not there yet), this recursive marking is done as can be seen below:

Let’s now see how it fits into the actual collection operation.

Collection

The actual collection process, including previously-examined marking phase, can be pictured with the following pseudo-code:

First of all, GC gets a list of all GC roots in the application (the list is maintained by JIT compiler and the runtime). Then it needs to iterate through each root and perform marking operation on it. Knowing that marking is a recursive operation, after this phase is finished, GC can be sure that all objects that have any root reference (either direct one or being pointed to by another objects) are added to the list of objects in use.

Next step is the actual memory releasing process of not used objects, represented as a call to Cleanup() method on the listing above. Memory cleanup itself is a very simple process – it’s just marking a particular memory block(s) as free (not used). There’s no overwriting of memory or anything like that (except ‘side overwriting’ which happens during heaps compaction – described below). Just simple boolean-like terminology is used for memory blocks – used (1) or not used (0). It works that simple for LOH , but collection on SOH (still don’t know what are LOH and SOH? Go and read here quickly!) also involves the compaction process. Let’s see what that is.

Heaps compaction

As we know from the first post, memory on the managed heaps can get fragmented, leaving holes of not used memory between live objects. That’s why the garbage collection for SOH process involves compaction, which is a process of removing the memory holes on the heap. It’s often referred to as a Copy Collection process, because it’s based on finding the dead objects or memory holes (it’s actually the same – holes of the memory that are not used by anything, present in-between live objects) and overwriting these holes with the live objects allocated later (next) on the heap – by copying chunks of live objects ‘down in the heap’.

The result of the compaction process is the contiguous SOH, where objects are allocated on top of each other with no or minimal possible number of memory holes.

Finally, addresses to the objects stored in reference variables are updated in order to point to the correct, new places in the memory occupied by particular object.

The best gain we get from the compaction is that the SOH is not fragmented, so the memory can be used efficiently. On the other hand it requires some CPU time, which may have some impact on our application’s performance.

By default, LOH is not compacted because of the size of objects stored on it (>85 kilobytes). Copying chunks of such objects would take too much time. Instead, used space and memory holes on the LOH are tracked and the allocation algorithm is adjusted to try to reserve the memory for new objects in the optimal way (by finding the best possible free slots on the fragmented heap).

What’s worth noticing is that starting from .NET Framework 4.5.1, LOH compaction can be enabled on demand by using GCSettings.LargeObjectHeapCompactionMode property.

When does the GC run?

It can be stated that GC works in a non-deterministic manner. It runs on a separate thread when one of the following conditions becomes true:

•  the OS sends low memory notification,
• the memory used by the objects on the managed heap exceeds some defined threshold (which is adjusted dynamically at runtime, based on current allocations),
• GC.Collect() method is called in the code.

If you see GC.Collect() directly used in code, in almost every case it means that there’s something wrong with the application’s implementation. Several great Microsoft engineers and open-source contributors have worked on automatic garbage collection in order to not trigger it manually

The exceptions for this rule I’d accept are maybe some gaming implementations, in which you work with huge objects and sometimes you’d like to affect the way when these objects’ memory is cleaned-up or usage in debugging – most of memory profilers (like dotMemory or ANTS Memory Profiler) force the collection before the memory snapshot is done by the user. This is reasonable, because when debugging memory leaks or issues you wanna see which objects remain allocated after GC does its cleanup.

What’s also worth mentioning is that when the garbage collection is run, all threads are stopped by default, except the thread in which the collection was triggered. However, this can be configured by changing the GC’s settings to work in workstation or server mode, as well as making it run concurrently or in the background. There are different use cases in which each settings combination should be used – you can find more details about it here and here.

Summary

Today we’ve covered the main blocks from which the garbage collection process in .NET is built. We went through marking phase, then the actual collection process – also including heaps compaction. We learnt how the GC roots tree is built and how garbage collector knows which objects it can clean-up during its cycle. We also listed cases in which the collection can be triggered.

In the next post we’ll examine a very interesting concept – generational garbage collection.

See ya next week!

The post [.NET Internals 05] Garbage collection: marking, collection and heaps compaction appeared first on CodeJourney.net.

Ready? Let’s start then!

What (or who) is Garbage Collection (Collector)?

As you could read in the previous posts on internal details of .NET,  there are a lot of conditions and assumption of memory organization in the framework. Data is stored on the proper structures, sometimes boxed and unboxed, but what’s the best about it all is that it’s almost completely invisible for us – developers.

In fact, providing this invisibility is a goal of Garbage Collector (GC). It should become our close friend (it’s not that scary as you could have heard – we’ll see that soon ), because this automatic memory manager does a lot of stuff for us, including:

• allowing us to write code without having to release memory (still remember the meme about C++?),
• performing heap allocations in an efficient way,
• reclaiming the objects that are no longer used and clearing their memory,
• ensuring that every new managed object gets clean content to begin with, so there is no work to be done in an object’s constructor to allocate the memory for all its members,
• providing memory safety, so one object cannot use the memory reserved for another object.

The term ‘garbage collection’ was firstly used in LISP programming language in 1959 and since then it represents the concept of automatic memory management in programming languages and frameworks.

Does GC allocate or deallocate the memory?

There’s often this confusion between allocating and deallocating the memory – what is actually responsible for that? In principle, the goal of garbage collector is to deallocate the memory – as its name suggests, it collects (frees, reclaims) the garbage (not-anymore-needed objects).

On the other hand, when there’s any memory allocation request sent by an application, such query is transferred to CLR, which is actually responsible for allocating the memory. However, as we’ll see in the coming posts, the deallocation of memory (which is much more complex process that allocating it) can be triggered on various conditions and it can happen that allocation of the memory requires deallocation to be performed first. It doesn’t mean that this is a sequence of events (i.e. before allocation the deallocation is performed), but that the number of allocations done by the CLR can affect the way and frequency of garbage collections (we’d like to have available memory when an allocation is to be done).

That’s how the CLR ‘asks’ GC for help (or ‘communicates with GC’ by notifying it about allocations) in actually allocating the memory (for instance by making GC running a collection or heap compaction process more frequently). Because of that reason, it’s usually simplified that garbage collector handles both allocation and deallocation of memory.

As we’ll see below, allocation of memory is as simple as 1 + 2 = 3 – continue reading to get to know why!

Memory allocation in .NET

As we read in the first post of the series, each process has its own virtual address space. Garbage collector is responsible for allocating the memory on the managed heaps (more about heaps here) created in this process’s space. It means that garbage collector only takes care of reference type objects.

Value types are stored on the stack in LIFO order and their memory is reclaimed as soon as the method in which these value types are defined exits. It would make no sense if GC had to manage these theoretically simple and (in a perfect world) locally declared variables.

Next object pointer

To make it simple, as soon as managed heap is created, it contains a pointer to the memory address where the next object will be allocated. This pointer is simply a number and is referred to as next object pointer. Initially, its value is set to managed heap’s base address:

As soon as the first-ever reference object is to be allocated on this particular heap, the memory is allocated in the place where the next object pointer currently points to. State of the heap after first allocation would be something like that:

As presented above, the next object pointer is moved to the address just after the allocated object. It ensures that there are no unnecessary memory gaps on the heap.

Complexity of memory allocation

In reality, the next object pointer’s value is a number in hexadecimal format (e.g. 0xF7279). When a new allocation is to be made, the only operation to perform is an addition operation. It is known how much space is needed for the new object (more details in the next section), so in order to reserve the proper memory chunk, number of bytes necessary for a new object is added to the next object pointer’s current value.

This is how the reservation of managed memory works. Because of that it can be said that allocating the memory for reference types is almost as fast as allocating variables on the stack.

If you’d like to see how you can check the memory address of an object, I recommend checking this article.

How is an object’s size calculated?

In the comments under the previous post, Jelena asked for explanation on how the size of an object is calculated. Here it comes

As we all know from the second post, object is sometimes allocated on the Small Object Heap (SOH) or Large Object Heap (LOH) depending on its size. For that reason before the allocation is made, the object’s size must be determined. How is this size calculated then?

It would make things easy to assume that size of an object is everything it contains (also other objects’ sizes). In reality, it’s not counted this way. Objects contained in another objects are allocated separately on the heap, so their actual sizes are not included in the parent object’s size.

Very good example is given in Chris Farrell’s and Nick Harrison’s book – Under the Hood of .NET Memory Management. If we consider the following code:

That’s how the heaps’ state looks like as soon as as instance of MyClass is created:

The size of MyClass object instance will include:

• general class stuff (e.g. some metadata – you can check it yourself in IL code with ILSpy as we did with boxing and unboxing),
• memory required to store the pointers (memory addresses) to the string and bytes array.

string Test will be allocated on the SOH, and byte[] data will be allocated on the LOH (it’s more than 85K).

In general, the size of an object is calculated by adding sizes of:

• general class data,
• pointers (for reference types class members) containing only addresses in memory (hexadecimal numbers),
• value types (for value types class members) – more details here.

Summary

I hope this post makes the role of garbage collector a bit more clear for you. We’ve also seen how easy the memory allocation is and what’s the general way of calculating an object’s size.

Even we don’t perform the actual allocations ourselves manually and may think like this guy:

We’ll see if that’s true next week, when we’ll dig into more complex topic, the real purpose of the GC – releasing the memory!

Stay tuned!

The post [.NET Internals 04] What is Garbage Collection? Memory allocation in .NET appeared first on CodeJourney.net.

What is boxing and unboxing?

In the previous post we learnt what are value and reference types and got to know that the former are stored on the stack, whereas the latter are stored on the managed heap. So why should we care? Isn’t it .NET runtime which correctly manages these data structures and what’s stored on them so we don’t need to worry about that?

In fact, no. What’s crucial to know and understand are the implications of moving data from the stack to the heap and otherwise.

Remember:

• when any value type variable is assigned to a reference type variable, data is moved from the stack to the heap and this is called boxing,
• when any reference type variable is assigned to a value type variable, data is moved from the heap to the stack and this is called unboxing.

Microsoft Docs examples illustrate these actions very well.

Consider the following example of boxing:

and the memory state as it executes:

In order to store “123” value in an object, the “box” is created on the heap and the value is copied inside it.

On the other hand, when unboxing happens:

that’s how stack’s and heap’s content changes:

Value “123” is taken out of the “box” and placed back on the stack.

Notice that when i value type is boxed into object o, there’s a reference stored on the stack and the actual memory is allocated on the heap (as for all reference types). As soon as the unboxing happens, the real data being on the heap must be copied to the stack (variable j). In both cases our goal is to deal with the same value (123).

As you can imagine, these operations produce some additional cost and affect the performance, which we’ll discuss in a moment.

Let’s see some IL

When analyzing such performance or memory management aspects in our code (C# in that case), it’s often worth to see how the Intermediate Language (IL) looks like.

We haven’t covered this concept yet, but as you probably know when C# code is compiled into DLL or EXE, these output files actually contain the IL code, which is later JIT-compiled and executed by the virtual machine (more details here). The .NET runtime must somehow know whether is should box or unbox the particular variable, as it requires some special memory allocation actions to be taken.

Let’s create some simple .NET Console Application with the following code in its Main method:

Let’s compile the application so we can find BoxingUnboxingTest.exe file in the output directory. Now we will use ILSpy to see the IL code inside the executable.

As soon as the EXE file is opened in ILSpy, we can go directly to see Main(string[]) : void method’s compiled content, choosing “IL with C#” view to make it simpler for us:

Notice the box statement just after the assignment of value type to reference type happens (object obj = num). Similarly for unbox.any statement just after assignment of reference type to value type (int num2 = (int)obj).

That’s how boxing and unboxing is represented in the IL.

When do we box and unbox?

The sample code above may seem naive and you may think “hey, but I never do such things”. That’s true in most cases, but values in our code are often boxed/unboxed even if we are not aware of that.

Non-generic collections

For instance, there still exists the old-school ArrayList collection:

which as you can see above has the Add method taking an object parameter. It means that when we’d like to add an integer to ArrayList:

boxing takes place:

Such issues were eliminated by generics and generic collections.

String concatenation

Another interesting example is the concatenation of strings with value types using “+” operator:

Such operation involves String.Concat method’s version taking two object parameters, so it implies boxing the integer first:

In order to avoid it, it’s enough to slightly modify the code by using ToString() method on the integer variable (for now ignoring ReSharper telling you it’s redundant ;)):

and there’s no boxing anymore, as now String.Concat method’s version taking two string parameters is used:

There could be many more cases to present, but the goal is that you get a strong feeling what boxing and unboxing is and when it occurs.

Performance implications of boxing and unboxing

As we already know, boxing and unboxing imply some cost. In case of simple stuff like concatenating the string once with some integer, the performance gain by introducing ToString on integer first is unnoticeable. That’s why, as I wrote before, even ReSharper tells you to not do it:

In that case it’s better to keep the clarity of the code without ToString method.

The perspective changes when you need to perform such operations in a loop for hundreds or thousands times. In this case the execution of code using boxing can be even 150% longer than its equivalent with no boxing (you can create a simple application and measure the execution time of code with and without boxing or check this article).

Boxed values also take more space in the memory than value types stored on the stack. Copying the value to/from the stack is also a cost. According to MSDN, boxing can generally take even 20 times longer that simple reference assignments, whereas unboxing can be 4 times slower than assignments.

So… why to use boxing and unboxing?

Despite all performance implications boxing and unboxing have, these concepts were introduced into .NET because of some reasons:

• there’s unified types system in .NET, which allows to “represent” both value and reference types in a similar way – thanks to boxing,
• collections could be used for value types before generics were introduced into .NET,
• it simplifies our code, like we saw for string concatenation and in most cases this clarity gives us much more than the performance we’d gain trying to avoid boxing.

Boxing and unboxing are so common that we can’t avoid them. We should be aware how it works in order to be able to minimize their usage, but it should always be considered reasonably. Don’t spend time on optimizing your code, checking IL all the time to get to the point with the smallest possible number of box statements used. Keep in mind that the clarity of your code, its self-explanatory structure and comfort of reading is sometimes much more valuable than some small or barely noticeable performance gain.

Summary

In today’s post we saw what is boxing and unboxing, how it’s represented in the IL code and what implications on performance it may have. I hope it clarifies these commonly mentioned concepts for you, at least a bit

If you’re interested in digging into nitty-gritty, low-level details of boxing and unboxing in .NET, I invite you to read this great post by Matt Warren about even more internal internals of boxing and unboxing

In the next posts in the series we’re going to start exploring the garbage collection. If you have any suggestions or ideas for the coming articles, let me know in the comments (some of you already did on reddit – new posts scheduled ).

See you (or better read you ) next week!

The post [.NET Internals 03] Boxing and unboxing appeared first on CodeJourney.net.

If you’re here for the first time, I encourage you to first read the .NET Internals series introductory post explaining the basics of memory structure.

Memory division

By default, when the .NET application is started and virtual address space is allocated for the process (as we saw in the previous post), the following data structures, represented as heaps, are created:

• Code Heap – storing JIT-compiled native code,
• Small Object Heap (SOH) – storing objects of size less than 85 kilobytes,
• Large Object Heap (LOH) – storing objects of size greater than 85 kilobytes*,
• Process Heap.

*side note: there’s an exception for arrays of double,  which are allocated on the LOH much before reaching 85K (double[] is considered “large” when it exceeds 1000 elements). This is for the sake of 32-bit code optimization. More details here and here.

Division of storing small and large objects on different heaps has its performance reasons, which will be covered in the next posts about garbage collection.

Elements placed on the heap have their addresses, which are a kind of pointers to the place in memory where the particular object is located.

Heap is however not the only data structure used by .NET process. There’s also a stack, which helps in tracking code’s execution and storing some special types of data. We’ll now see in details how stack and heap are used and organized.

Stack

Stack is a memory structure organized as LIFO (last-in-first-out) collection. If you think about it, it’s perfect for storing anything that may soon need to be used (easily popped out from the top of the stack). This nature of stack leads to its two main purposes: keeping track of execution order and storing value types variables.

Keeping track of execution order – call stack

Most of the code we write is wrapped into classes and methods, which can call another methods, which call another methods etc. .NET Framework must all the time keep track of this execution’s order. Moreover, it also has to remember the state of variables and parameters of the method calling another method, while this another method executes (to be able to restore the calling method’s state after the called method returns).

As soon as any method is called, .NET initializes a stack frame (kind of container) which stores all data necessary to execute the method: parameters, local variables and address of the line of code to go back to when the method finishes.  Stack frames are created on the stack on top of each other. Each method has its own stack frame. All that behavior is well illustrated on the figure below.

Stack used for storing the execution order is often referred to as call stack, execution stack or program stack.

Take a look at the following code:

In order to call Method2, the framework must save an execution return address which will be the next line of code to execute after Method2 finishes (line 4 in the example above). This address altogether with parameters and local variables of the calling and called methods are stored on the call stack, as the schema below presents.

You can also notice what happens when Method3 returns (its stack frame is popped out from the stack – it disappears).

Storing value types

Stack is also used to store variables of any of .NET value types, including bool, decimal, int etc. Full list of .NET value types can be found here.

Value types are basically the types which keep the data and memory in the same location. What’s also interesting to know is that all value-typed local variables of the method allocated on the stack are cleaned-up after the method’s execution finishes. It happens because the method’s stack frame becomes unreachable – stack has some pointer to the beginning of the top-level stack frame (current stack frame pointer), which is simply moved to the second stack frame from the top as soon as the method’s execution is finished (the data is still physically there, but it’s not reachable by default .NET mechanisms).

Heap

Heap is similar to stack, but if the stack can be imagined as a series of boxes stacked on top of each other, where we always push or pop the top one, heap contains boxes that can be accessed at any time. The boxes in the heap are placed in different places, not necessarily on the top of each other. To access one of the boxes we don’t need to pop out the top ones first.

Storing reference types

All other variables, which are not value types i.e. are either string or object (or deriving from one of these, so all classes, interfaces and delegates) are referred to as reference types. All reference types are allocated on the managed heap (SOH or LOH, depending on their size). However, even though an object is allocated on the heap, a reference to it (address on the heap) is stored on the stack.

Consider the following code:

The figure below presents how stack and heap would look like here in terms of allocated data:

The “OBJREF” stored on the stack is actually a pointer (reference) to the MyClass object on the heap.

NOTE:  MyClass myObj statement doesn’t allocate any space on the heap for myObj variable. It only creates “OBJREF” variable on the stack, initializing it with NULL value. By the time new statement is used, the actual memory allocation on the heap takes place and the reference’s value is set.

Value types vs reference types (stack vs heap)

The crucial difference between value and reference types is that when a value type variable is passed to another method as parameter or just assigned to another value type variable, its value is copied into the new variable. That’s why when passing a value type to another method, which modifies this variable (parameter), when the method returns the original variable’s value is not changed (it was its copy which was used inside the called method). Figure below shows this behavior.

It’s different in case of reference types. When reference type variable is assigned to another reference type variable (or method’s parameter), it’s not its value which is copied, but only the reference to it (address in the memory where the data is actually stored on the heap). In effect, the new variable (or method’s parameter) still points to the same place in memory, so modifying such reference type variable inside the called method will also be in effect outside of the method. This case is illustrated below.

Of course, storing some data on the stack and some on the heap (moreover: different types of heaps) has its precise purpose, which we’re going to explore in the coming posts

Summary

In today’s post we went through stack and heap, two data structures used for storing value and reference types and tracking execution order of .NET application. In the next posts in the series we will see what is boxing and unboxing and how it can affect application’s performance. We will also examine the garbage collection process in details.

Stay tuned!

The post [.NET Internals 02] Stack and heap – .NET data structures appeared first on CodeJourney.net.

Ever been surprised that there’s no need to worry about memory allocation and deallocation using high-level programming languages such as Java or C# after leaving the university* ?

Still remember (old) C++ times with delete statement?

By this post, I’d like to introduce a new “.NET Internals” series on the blog. I will be publishing a new post on .NET internal concepts every Wednesday. No end date for the moment

Posts within the series will be mostly about memory management and performance aspects of .NET applications. All discussed concepts are applicable to most of the modern programming platforms, but the examples will be based on .NET Framework.

If you’re interested in such topics, I encourage you to check this blog every Wednesday starting today

*there is 1 assumption and 1 fact here:

• assumption: you used to program in C/C++ (before C++11) on the university,
• fact: that’s not true you don’t need to worry about memory management using high-level programming languages; wait for the next posts to get to know why.

CLR

Each application targeting .NET is managed by CLR (Common Language Runtime), which is a part of .NET Framework, which must be installed on the computer on which the .NET application is launched – the exception are .NET Core self-contained apps, which we are not discussing in this series. By default, the CLR is loaded by each .NET process as a hosted process (so the CLR runs as a part of .NET application).

This CLR “layer” is responsible for various things while our application is running:

• executing CIL (Common Intermediate Language),
• ensuring type safety,
• handling exceptions,
• managing threads,
• garbage collection.

Memory structure

Already running application is represented as a process in the operating system. As software developers we know that such process saves some data into the memory, which is determined by the amount of RAM available on the computer. However, process never operates on this “open memory” – only OS has direct access to it. When the CLR is launched within .NET process, it requests some amount of RAM from the operating system. This memory chunk is called virtual address space. Each process has its own virtual address space, but all processes running on the same machine share the same physical memory.

32-bit OS

Do you remember 32-bit editions of Windows XP, which could only use 4GBs of RAM (with even less visible to the user)? The reason for that is that in 32-bit operating systems total virtual address space is 4GBs, usually divided into two equal chunks – first one owned by the OS and the second one prepared for user processes. The diagram below presents.

64-bit OS

In 64-bit Windows theoretical amount of virtual address space is 16 exabytes (2⁶⁴ bytes). In reality, only a part of it is used: 8-terabyte chunk is used for user space and portions of 248-terabyte are used for the OS:

Sharing memory between processes

What seems to be critical to understand is how this whole virtual memory is shared between processes. As we said before, multiple processes share the same memory, but accessing different (separate) chunks of it. Let us illustrate once more:

As can be seen, each process reserves different pages of memory when it’s needed. Even though the default 2GBs of virtual memory reserved for a single process may seem to be a lot, every developer needs to be aware that when an allocation (reservation of memory chunk) is made (manually or by memory management system) the virtual memory manager needs to find a single, continuous virtual memory block large enough to store the requested amount of data. This rule leads to the presence of “holes” in the memory. This virtual memory fragmentation is well-presented on the diagram below:

However, this requirement of finding a continuous block to be allocated refers only to the virtual memory. Physical memory is divided into pages, which can be stored in totally different places – as you can see on the diagram above with Notepad.exe application using continuous blocks of its virtual memory, but committed to noncontiguous pages scattered in various physical locations.

If the process requests for too much memory, which cannot be continuously allocated in the virtual address space (your process is out of virtual memory) or no more virtual memory can be committed (assigned) to the physical storage, it can result in OutOfMemoryException thrown by .NET code.

Summary

This was the introductory post of my new .NET Internals series. We saw what are the basic concepts of the memory structure, learnt what is virtual address space, how physical memory is shared between processes and why Windows XP was able to handle only 4GBs of RAM

See you next Wednesday!

The post [.NET Internals 01] Basics of memory structure appeared first on CodeJourney.net.

Why to keep and restore Activity’s state?

As I already described in my post about Android Activities, the OS may react to some “constant” state changes by calling lifecycle methods during Activity’s life, which may be overridden by the programmer in order to take some additional actions. However, there are some behaviors in Android apps that may change its configuration, after which the state of the Activity (for instance: arrangement or some UI elements or checkboxes’ selections) may be lost if not handled properly.

To give you a real example: in MoneyBack application there is a main screen with two tabs. I noticed that when the second tab is selected:

and the device is rotated:

first tab becomes selected. User is losing his input (selection of the 2nd tab).

Screen orientation change is one of the reasons why we should care about saving and restoring Activities’ states.

Keeping state changes – OnSaveInstanceState()

Each Activity allows us to override OnSaveInstanceState(Bundle outState) method, which is called when the current Activity is to be killed (e.g. when device’s screen orientation is changing or the Activity needs to be killed by Android in order to release some resources).

Please don’t confuse it with Activity Lifecycle Methods (which I already described here), like OnPause() or OnStop() which are always called by the OS when particular action occurs. OnSaveInstanceState() method is generally called after OnPause() and before OnStop(), but it’s not always the case. For instance, it won’t be called at all when user navigates back from ActivityB to ActivityA, as in this case ActivityB will never be killed. More details can be found in official Android documentation.

OnSaveInstanceState() is called with Bundle parameter provided. It represents a simple key-value dictionary, which is additionally serialized, so it should be used for storing simple values like strings, integers etc. There are other structures and techniques for storing more complex data on state changes events (see the link in “Summary” section of this post).

In order to save currently selected tab, we can implement the method as follows:

Now, each screen orientation change will make this method called and the index of selected tab will be saved into Bundle outState dictionary under “selectedTabPosition” key.

Restoring state changes – OnRestoreInstanceState()

As soon as the Activity considered backs to life (is being resumed), OnRestoreInstanceState(Bundle savedInstanceState) method is called by the OS. It will only be called if there is a saved instance kept by calling OnSaveInstanceState() method before. As you can see, this method also comes with a Bundle parameter, which is the same key-value serialized dictionary we used for saving the Activity’s state.

In case of tabs selection restoring, we can implement this method as the following code presents:

previouslySelectedTabPosition variable will be initialized with integer value from Bundle dictionary saved under “selectedTabPosition” key, or default value (0) if nothing saved for the key is found.

NOTE: Bundle parameter provided in OnRestoreInstanceState() is exactly the same, as the one available in OnCreate(Bundle bundle) method called on Activity’s creation. We could actually also retrieve our saved value there, but in many cases restoring the state (like selecting previously selected tab) requires some UI elements to be already initialized, which should be handled within OnCreate() method before. Because of that, I’d rather suggest to restore Activity’s state using OnRestoreInstanceState() as a general rule (of course there may be some exceptional cases ). OnRestoreInstanceState() will always be called after OnCreate().

Moreover, if we wanted to use Bundle parameter in OnCreate() method, we’d need to check each time if bundle is not NULL (as we don’t know whether OnSaveInstanceState() had been called before).

As a result, the same tab as previously is selected even after rotating the device on MoneyBack‘s MainActivity:

“Automatic” state changes handled by Android OS

Maybe you noticed in your Android application, that not every UI element needs to be handled “manually” by implementing the above-mentioned methods in order to save its state. Android performs some kind of “automatic” saving and restoration of basic UI elements’ states.

The rule here is that as long as UI element (like TextView or Button) has its android:id set in .axml layout file, OS will automatically manage those elements’ states (e.g. text entered into EditText).

For example, for EditText declared like that:

its properties (especially its Text property) will be automatically saved and restored on screen orientation changes.

Summary

We’ve seen how to handle Android Activities’ state changes caused by configuration modification (e.g. screen orientation change, Activity being killed by the OS in order to free some resources etc.) by implementing OnSaveInstanceState() and OnRestoreInstanceState(), where we added and retrieved key-value data to/from Bundle serialized dictionary. We just need to remember that those methods are not always called (e.g. when navigating between Activities using “back” button), so these should be used only for certain kind of state changes.

We’ve also seen that UI controls with their android:id defined in layout files have their states resistant for configuration changes (handled automatically by Android OS).

Bundle dictionary is serialized for better performance and memory utilization, so only simple-typed values should be stored in it (like strings or integers). In order to store more complex data, Android provides different possibilities of managing it (e.g. using OnRetainNonConfigurationInstance).

The post Managing Activity state changes using Bundle appeared first on CodeJourney.net.

The dialog looks as follows:

It may be opened e.g. when clicking on a button in the app, as I used it in MoneyBack.

Creating DatePickerFragment

First of all, we will implement the dialog to be displayed within DialogFragment. Doing that our dialog will be able to be displayed as independent piece of UI on the top of any Activity.

The second requirement is to implement IOnDateSetListener interface (coming from Java/Android), which provides a callback on date selection action done by the user.

The DatePickerFragment meeting those two requirements may look as follows:

There are few crucial parts in above-listed class:

• Line 1: as said before, the class derives from DialogFragment and implements IOnDateSetListener interface
• Line 3: here we have public static readonly string TAG variable defined – it is used as a unique identifier of the Fragment; in some cases, Fragments can be displayed without any UI – in such case the only possibility to identify and get the Fragment is by using findFragmentByTag() method
• Lines 5-10: define _dateSelectedHandler delegate which may be provided to the constructor of our DatePickerFragment with the method to be called-back when user selects a date
• Lines 12-20: inheriting from DialogFragment allows us to override its lifecycle methods – one of them is Dialog OnCreateDialog(Bundle savedInstanceState), in which we actually create the Dialog-inheriting class – in our case – DatePickerDialog – with initially selected date (set to current date in the provided example)
• Lines 22-26: implementing IOnDateSetListener interface requires to implement OnDateSet method, which is called when the user selects the date and clicks “OK” button;
  NOTE: one of this method’s arguments is monthOfYear integer value, which contains month number expressed as values 0-11 (NOT 1-12) for compatibility with java.util.Calendar.MONTH

Using DatePickerFragment

In MoneyBack application I’ve used DatePickerFragment on creating/modifying an event, when user needs to select its date:

As soon as the button is clicked, the following code executes:

As you can see, to DatePickerFragment‘s constructor I’m providing the delegate with a method to be called when the date is selected by the user (setting _selectedDate property with selected time and putting the date in short format as button’s Text).

In order to display a dialog, Show method is called, taking current FragmentManager and already mentioned per-Fragment-unique tag string, defined statically in DatePickerFragment class.

Summary

Today’s short post presented how to easily create a DialogFragment showing DatePickerDialog for date selection, which allows to provide any method to be called-back when the date is selected by the user.

I hope you’ll find it useful

The post Date selection using DatePickerDialog in Xamarin.Android appeared first on CodeJourney.net.

One-to-many, many-to-one

One-to-many relationships are used in general for parent-children or whole-elements relations. Classic examples are: bus and passengers, document and elements etc.

One-to-many relationship means that the one-end entity knows about its children and many-end entity has a reference (foreign key) to its parent (but not necessarily knows about it).

On the other hand, the opposite relationship to one-to-many is many-to-one. In that case, many-end entity has a reference to its parent and knows about it, but the one-end entity doesn’t necessarily know about its children (at least not directly).

I used a verb to know several times – so it’s time to explain it 🙂 By “knowing” about the other end of a relationship I understand having a reference to it. It means that, for instance, in many-to-one relationship, the one-end of it doesn’t have a reference to its children.

However in most cases what we’d like to have is a hybrid of one-to-many and many-to-one relationships. I will call it one-to-many with inversion. We want both parent to know about its children, and each children to know about its parent.

In this post we’ll cover one-to-many with no reversion and one-to-many with reversion, as it also includes many-to-one relationship so you can have a comprehensive overview. We are going to see it on the example of Employee and Duty* entities. Each employee has a list of his duties, whilst each single duty is assigned to only one employee.

* “Task” would probably be a better name, but I didn’t want to make it confused with .NET Tasks 🙂

One-to-many with no inversion

Firstly, let’s model this kind of relationship:

Now we can transform it into C# classes:

In the Employee class (parent, one-end of the relationship) we define the collection of children, decorated with OneToManyAttribute. Collections types supported as for the time of writing this post by SQLite-Net Extensions are List and Array and can be used as you prefer.

Let’s now see how the child entity (Duty) looks like:

In the Duty class (child, many-end of the relationship) we need to have a foreign key to parent entity defined. For that purpose, we create a property representing it (EmployeeId), decorating it with ForeignKeyAttribute, additionally specifying the type of parent referenced (Employee).

That’s it. We can already use it in our code:

No rocket-science here. What’s interesting for us it how employeeStored looks in the end:

As you can see, GetWithChildren method returned object of type Employee with its Duties collection properly retrieved (containing two duties assigned to the employee before). Moreover, each children has its foreign key (EmployeeId) automatically retrieved from the DB – there is no overhead here, this is simply foreign key field stored in the same SQLite database table (Duties).

One-to-many with inversion (one-to-many + many-to-one)

As previously, let’s first see how the class diagram changes after adding inversion:

What changed is that now each Duty has a property of type Employee.

To realize the above class diagram and make each children (each Duty in our case) knowing about its parent (having a reference to responsible Employee), the only thing we need to do is to add the following property to Duty model class:

[ManyToOne]
public Employee Employee { get; set; }
so the model class finally looks as follows:








  





  [Table("Duties")]



  public class Duty



  {



      [PrimaryKey, AutoIncrement]



      public int Id { get; set; }








      public string Description { get; set; }








      public DateTime Deadline { get; set; }








      [ForeignKey(typeof(Employee))]



      public int EmployeeId { get; set; }








      [ManyToOne]



      public Employee Employee { get; set; }



  }






        view raw

        

          Employee_withInv.cs

        

        hosted with ❤ by GitHub
      


As you can see, we have just created many-to-one relationship by using ManyToOneAttribute. So currently we have the hybrid of both types of relationships within out two models.
The usage in our code doesn’t need to be changed at all. Now, employeeStored entity after being initialized by the same GetWithChildren method as previously, for each Duty in addition to EmployeeId field also contains Employee property properly retrieved by SQLite-Net Extensions:

Again, there is no db overhead here, because when retrieving Employee entity from the database we already have it, so the operation of initializing the Employee entity in each Duty contained within Duties collection doesn’t require any more database querying.
Summary
Today we’ve seen how to model and use one-to-many (with and without inversion) relationships in SQLite database with the usage of SQLite-Net Extensions. The automatic initialization of one-end or many-end entities by the ORM is extremely helpful when dealing with such kind of objects in our app. The amount of code to be written is also minimal.
We’ve covered one-to-many and a hybrid of one-to-many + many-to-one relationships, but of course you can also define just many-to-one relationship – the models would then look as in this Gist. For me, it makes very limited sense, but maybe can be useful in some specific situations.
I invite you to read my other posts about SQLite-Net Extensions ORM, where we also covered the other types of relationships that can be modeled using this library.
As this is already the third post from this series, I’d like to ask you: what do you think about SQLite-Net Extensions ORM? Do you find it useful? Do you use it in your apps? Can you can recommend some other libraries/ORMs to use with SQLite database that allow to model different kind of relationships?
The post SQLite-Net Extensions – one-to-many relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-many-relationships/feed/
			2
		
		
		2251	
		
		
		https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/#comments
		
		
		Sun, 21 May 2017 10:18:15 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2238

					In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM. One-To-One This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated…

The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
										In this second short post from SQLite-Net Extensions series, we’re going to see how to create one-to-one relationships using this tiny ORM.


One-To-One
This is the simplest type of database relationship. An example could be vehicle and registration certificate – each vehicle has one and only one registration certificate, and one registration certificate is associated with one and only one vehicle (excluding some extraordinary law rules in other countries that I don’t know  ).
We can model it in two ways:

as a one-way relationship – in this case only one of the relationship’s ends knows about the other one
as a both-ways (with inversion) relationship – both relationship’s ends know about each other.

One-To-One with no inversion (one-way)
This kind of relationship looks as follows:

We use it when we assume it’s enough that Vehicle knows about RegistrationCertificate, but the document doesn’t necessarily need to know which car/motor it’s associated with (at least directly).
In the code, we then create two model classes using SQLite-Net Extensions:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }



    }






        view raw

        

          RegistrationCertificate.cs

        

        hosted with ❤ by GitHub
      










  





    [Table("Vehicles")]



    public class Vehicle



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Brand { get; set; }








        public DateTime ProductionDate { get; set; }








        public decimal EngineCapacity { get; set; }








        [ForeignKey(typeof(RegistrationCertificate))]



        public int RegistrationCertificateId { get; set; }








        [OneToOne]



        public RegistrationCertificate RegistrationCertificate { get; set; }



    }






        view raw

        

          Vehicle.cs

        

        hosted with ❤ by GitHub
      


What’s interesting here is the ForeignKeyAttribute defined on RegistrationCertificateId property. It is – as its name says – the foreign key to the primary key of related entity (of type RegistrationCertificate).
The related entity property itself is decorated with OneToOneAttribute.
There’s nothing more we need to do to have this relationship modeled. We can already use it:








  





    var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



    db.CreateTable<Vehicle>();



    db.CreateTable<RegistrationCertificate>();








    var vehicle = new Vehicle



    {



        Brand = "Renault",



        EngineCapacity = 1.9m,



        ProductionDate = new DateTime(2001, 01, 01)



    };








    var certificate = new RegistrationCertificate



    {



        RegistrationNumber = "AB 12345",



        OwnerData = "Dawid Sibiński",



        VIN = "1312BS1312ASDSSVVW"



    };








    db.Insert(vehicle);



    db.Insert(certificate);








    vehicle.RegistrationCertificate = certificate;



    db.UpdateWithChildren(vehicle);








    var vehicleStored = db.GetWithChildren<Vehicle>(vehicle.Id);






        view raw

        

          OneToOne_noInv.cs

        

        hosted with ❤ by GitHub
      


Nothing special here, right? It looks very similar to what we’ve seen in the previous post about many-to-many relationships. What’s interesting for us it that in the end, when Vehicle object is retrieved from the database using GetWithChildren method, its RegistrationCertificate property is filled as well:

One-To-One with inversion (both-ways)
This kind of relationship models itself as below:

What actually changed on the diagram compared to the relationship with no inversion is that now RegistrationCertificate has a property of type Vehicle (in the code – a reference to Vehicle related object and a foreign key).
In our case, this is even more “real” – it would be nice if a Vehicle knows about its RegistrationCertificate, but also when we look at the certificate we’d like to see to which car it belongs.
We can now model it in the code. The only thing that changes in the model classes is addition of a reference and foreign key to Vehicle in RegistrationCertificate model, so I’m presenting only this class’s updated code:








  





    [Table("RegistrationCertificates")]



    public class RegistrationCertificate



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string RegistrationNumber { get; set; }








        public string VIN { get; set; }








        public string OwnerData { get; set; }








        // added to have Inversion relationship



        [ForeignKey(typeof(Vehicle))]



        public int VehicleId { get; set; }








        [OneToOne]



        public Vehicle Vehicle { get; set; }



    }






        view raw

        

          RegistrationCertificate_withInv.cs

        

        hosted with ❤ by GitHub
      


What’s cool here is that we don’t need to modify our code for saving entities with relationships into SQLite database. We can simply add the following line at the end:
var certificateStored = db.GetWithChildren&lt;RegistrationCertificate&gt;(certificate.Id);
and notice that certificateStored already contains its associated Vehicle object:

Summary
In today’s short post we’ve seen how to create one-to-one relationship between two entities in SQLite database, using SQLite-Net Extensions ORM. It’s very easy and doesn’t require using Entity Framework  or writing SQL queries directly in our code.
We’ve covered two types of one-to-one relationships: one-way and both-ways. The choice between those two depends on the usage and purpose of the relationship we model.
I hope you’ll find it useful one day 
The post SQLite-Net Extensions – one-to-one relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-one-to-one-relationships/feed/
			2
		
		
		2238	
		
		
		https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/
					https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/#comments
		
		
		Thu, 18 May 2017 21:23:31 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2218

					In today’s post we’re going to see what is SQLite-Net Extensions ORM and how to use it to create many-to-many relationship in SQLite database. The other types of relationships will be described in separate posts. What is SQLite-Net Extensions ? As you develop any mobile app, sooner than later you need to keep your app’s data…

The post SQLite-Net Extensions – many-to-many relationships appeared first on CodeJourney.net.
]]>
										In today’s post we’re going to see what is SQLite-Net Extensions ORM and how to use it to create many-to-many relationship in SQLite database. The other types of relationships will be described in separate posts.


What is SQLite-Net Extensions ?
As you develop any mobile app, sooner than later you need to keep your app’s data in some persistent storage. In my MoneyBack project I’ve chosen SQLite database using SQLite.NET library for performing operations on it. This is actually very simple and easy-to-use database framework, but I recently realized I need to model some relations in my database.  SQLite.NET doesn’t offer any nice utilities to model such relations.
However, if you need to model any relations in your SQLite database, there is a wrapper on SQLite.NET which allows to do that – it is SQLite-Net Extensions. It basically extends the core functionalities of SQLite.NET by adding elements that allow to easily handle relationships, including one-to-one, one-to-many, many-to-one and many-to-many.
In this post we are going to see how to create many-to-many relationship using this library. I needed this kind of relationship to model the connection between Person and Event entities in my app.
Many-to-many relationship
Let’s see many-to-many relationship on an example of two entities: Person and Event. An event (entity of type Event) may contain zero or more participants (entities of type Person) whilst a person may be assigned to zero or more events. This is a typical many-to-many relationship which we are going to set up in our database now.
Install SQLite-Net Extensions
If you’ve previously been using SQLite.NET in your project – uninstall it first. I didn’t do it before starting to use SQLite-Net Extensions and I have many troubles with Visual Studio resolving my references incorrectly. SQLite-Net Extensions is a wrapper for SQLite.NET, so it already contains this library and additionally extends it by adding some extra functionalities for handling relationships.
SQLite-Net Extensions can be installed as a Nuget package into your solution. According to the version you’d like to use, execute appropriate command in Package Manager Console in Visual Studio:

synchronous:
Install-Package SQLiteNetExtensions -Version 1.3.0

asynchronous:
Install-Package SQLiteNetExtensions.Async -Version 1.3.0


Define model classes
Next we need to define our Person and Event model classes and establish the relationships between them. Below, you can find the code of both classes:








  





// Person class modelling People table



[Table("People")]



public class Person



{



    [PrimaryKey, AutoIncrement]



    public int Id { get; set; }








    public string Name { get; set; }








    public string LastName { get; set; }








    public string PhoneNumber { get; set; }








    public string Email { get; set; }








    [ManyToMany(typeof(PersonEvent))]



    public List<Event> Events { get; set; }



}













// Event class modelling Events table



[Table("Events")]



public class Event



{



    [PrimaryKey, AutoIncrement]



    public int Id { get; set; }








    public string Name { get; set; }



    public DateTime Date { get; set; }



    public string Place { get; set; }








    [ManyToMany(typeof(PersonEvent))]



    public List<Person> Participants { get; set; }



}






        view raw

        

          Person_Event.cs

        

        hosted with ❤ by GitHub
      


As you can see, the models look almost the same as SQLite.NET db entities, with the following exceptions:

ManyToManyAttribute – on both entities you can notice this attribute defined. On Person model class I decorate Events collection with it whereas on Event model class I decorate Participants collection with it. Simple as that.
PersonEvent – you may have noticed that as an argument to ManyToManyAttribute on both models I passed PersonEvent type. As you may know, in modelling many-to-many relationships we need an intermediate entity in order to store such kind of relationship in the database tables. The classic example is Student-Course relationship:


We also need to define such intermediate entity in our code.


The implementation of PersonEvent intermediate model class looks as follows:








  





public class PersonEvent



{



    [ForeignKey(typeof(Person))]



    public int PersonId { get; set; }








    [ForeignKey(typeof(Event))]



    public int EventId { get; set; }



}






        view raw

        

          PersonEvent.cs

        

        hosted with ❤ by GitHub
      


Thanks to PrimaryKey attributes defined on Person and Event entities the ORM will be able to determine to which primary keys the foreign keys in this intermediate table relate.
In the ManyToManyAttribute, except the type of intermediate entity, you can set CascadeOperations, which specifies how the cascading should be handled when working with the entities (e.g. if cascade delete operation should be performed when one of the relationship’s sides is removed).
Inserting and reading data
As soon as our model classes are defined, we can write and read the data with many-to-many relationships. The following code presents a simple way to create a new person and assign it to an event:








  





var db = new SQLiteConnection(new SQLitePlatformAndroid(), Constants.DbFilePath);



db.CreateTable<Person>();



db.CreateTable<Event>();



db.CreateTable<PersonEvent>();








var event1 = new Event



{



    Name = "Volleyball",



    Date = new DateTime(2017, 06, 18),



    Place = "Sports hall"



};








var person1 = new Person



{



    Name = "A",



    LastName = "B",



    PhoneNumber = "123456789"



};













db.Insert(person1);



db.Insert(event1);








person1.Events = new List<Event> { event1 };



db.UpdateWithChildren(person1);








var personStored = db.GetWithChildren<Person>(person1.Id);



var eventStored = db.GetWithChildren<Event>(event1.Id);






        view raw

        

          SavingPersonEvent.cs

        

        hosted with ❤ by GitHub
      


Lines 1-4 contain the database initialization (Constants.DbFilePath just returns an Android path of SQLite database file) and creation of all 3 tables in the database.
Lines 6-18 are simply the creation of Person and Event objects, filled with most basic details.
In lines 21 and 22 we firstly save our person1 and event1 entities separately, because in order to establish the relationships we need the primary keys of those entities, that are assigned by the database while saving. This can be also simplified by using recursive operations – more details in the official documentation of the ORM.
After that, we assign just created person to the event (line 24) and then the most rocket-science part comes:
db.UpdateWithChildren(person1);
This method does the write magic – it updates the person with all its children – so in our case, the Events collection. It will make the relationship established.
In order to prove it, in lines 27 and 28 we can check if the relationship collections are populated with children in both entities by calling GetWithChildren extension methods:
 

That’s how SQLite-Net Extensions ORM works. It doesn’t provide any lazy-loading of related entities – it just adds/retrieves to/from the database exactly what you tell it to. The limitation here is that if you access Person.Events collection you can see the events this person is in relation with, but if you access Person.Events[0] you will not see all people registered for this event.
Summary
SQLite-Net Extensions is an ORM, which is a wrapper for classic SQLite.NET library. It adds the extension methods/attributes to handle relationships in SQLite database. It doesn’t provide any lazy-loading mechanism, instead exposing methods for getting/saving entities along with their children (related entities). It’s lightweight and rather easy to implement, so for small solutions like mobile apps I totally prefer it to writing and maintaining SQL queries directly in C# in order to handle relationships.
In the next posts from the series about SQLite-Net Extensions ORM, I will present to you the other types of relationships this ORM offers. Stay tuned 
 
The post SQLite-Net Extensions – many-to-many relationships appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/sqlite-net-extensions-many-to-many-relationships/feed/
			8
		
		
		2218	
		
		
		https://www.codejourney.net/moneyback-3-weeks-before-the-end-of-dsp/
					https://www.codejourney.net/moneyback-3-weeks-before-the-end-of-dsp/#respond
		
		
		Tue, 09 May 2017 22:09:45 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=2192

					In today’s post I’d like to present what’s the current status of works on MoneyBack application, 3 weeks before the end of DSP competition. In general, the project hasn’t been going as well as I expected and is currently not as advanced as I’d expect it to be at this stage. There are many reasons behind that,…

The post MoneyBack – 3 weeks before the end of DSP appeared first on CodeJourney.net.
]]>
										In today’s post I’d like to present what’s the current status of works on MoneyBack application, 3 weeks before the end of DSP competition.


In general, the project hasn’t been going as well as I expected and is currently not as advanced as I’d expect it to be at this stage. There are many reasons behind that, including lack of time recently and many issues met during development, however, as I already wrote in my DSP introducing post, the most important is to survive with the project to the end of the competition and meet all requirements. The end of DSP doesn’t equal the end of MoneyBack 
That’s why in this post I’d like to show you how the project looks currently and what’s still to be done. Moreover, as I promised before, I’m publishing my Trello board with tasks still to be done within the project.
UI changes
For the last days working on the project I’ve been trying to make the UI of MoneyBack some kind of “final” version, so I can easily extend it adding new functionalities and focus on development instead of spending time on interface design, which is not important for me at the moment. I met many issues with that, which I think came from using some deprecated UI elements I used (e.g. ListView and Adapters) that are not fully-supported in the newest versions of Android. Tutorials are also not really up-to-date for those components. Maybe that’s also because when I wanted to implement displaying a list of entities I looked in Google for something like “xamarin android list of elements” which lead me to this ListView and Adapters tutorial. Instead of firstly reading the whole User Interface tutorial, I wanted to implement displaying the list quickly, so I used those deprecated elements instead of implementing for instance newer and recommended RecyclerView from the beginning, which would be easier extensible now. That definitely teaches me that I should get to know a particular topic/area better and wider before deciding to use one of the possible solutions to solve a problem. Sometimes we want to implement something particular quickly, but later it produces more issues than benefits.
Finally I added tabs (only one tab for People for now, but it will be easy to add new ones now) and ActionBar menu on the main Activity of the app:

On the screenshot above, in the right-upper corner there is “Add” button visible when clicking on ActionBar menu. It opens a new person’s adding screen, on which I made name and email fields mandatory:

People added are then displayed on the main screen of the app in “People” tab:

Code – interesting parts
Using tabs layout in an Activity
It turned out that using tabs-like layout in the Activity is pretty easy. In the AXML layout file for MainActivity I just added a FrameLayout container, within which the tabs and their contents are to be displayed:








  





<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"



    android:orientation="vertical"



    android:layout_width="match_parent"



    android:layout_height="match_parent"



    android:minWidth="25px"



    android:minHeight="25px">



    <FrameLayout



        android:minWidth="25px"



        android:minHeight="25px"



        android:layout_width="match_parent"



        android:layout_height="match_parent"



        android:id="@+id/tabFragmentsContainer" />



</LinearLayout>






        view raw

        

          Main.axml

        

        hosted with ❤ by GitHub
      


I called it tabFragmentsContainer, because within each tab we will display a Fragment. Fragment represents a part of UI and/or behavior, which is displayed within an Activity. You can think of Fragments as smaller pieces, that can be placed onto (inside) Activities.
Basically, I changed PeopleListActivity to PeopleListFragment, which in fact only required changing inheritance from being a child of Activity to inheriting from ListFragment (which is a special kind of Fragment used for displaying lists of elements). The complete code of PeopleListFragment can be found in this public Gist.
In the end, making MainActivity displaying tabs requires setting its ActionBar’s navigation mode to ActionBarNavigationMode.Tabs:
this.ActionBar.NavigationMode = ActionBarNavigationMode.Tabs;
and adding as many tabs as you wish, using for instance code similar to the following one:








  





void AddTab(string tabText, Fragment view)



{



    var tab = this.ActionBar.NewTab();



    tab.SetText(tabText);








    tab.TabSelected += delegate (object sender, ActionBar.TabEventArgs e)



    {



        var fragment = this.FragmentManager.FindFragmentById(Resource.Id.tabFragmentsContainer);



        if (fragment != null)



            e.FragmentTransaction.Remove(fragment);



        e.FragmentTransaction.Add(Resource.Id.tabFragmentsContainer, view);



    };



    tab.TabUnselected += delegate (object sender, ActionBar.TabEventArgs e) {



        e.FragmentTransaction.Remove(view);



    };








    this.ActionBar.AddTab(tab);



}






        view raw

        

          MainActivity_AddTab.cs

        

        hosted with ❤ by GitHub
      


The arguments are name of the tab and an instance of a Fragment we want to have displayed in this tab (PeopleListFragment‘s instance in our case).
Lines 6-12 present what happens when the tab is selected by the user – Fragment‘s instance is added to previously defined tabFragmentsContainer.
Lines 13-15 define callback method on tab deselection – Fragment is removed from the container.
Adding ActionBar with menu to the Activity
Addition of ActionBar with menu button in right-upper corner of the Activity requires creating an XML view in Resources/menu folder first (with one button in our case):








  





<menu xmlns:android="http://schemas.android.com/apk/res/android">



  <item android:id="@+id/menuAdd"



        android:title="@string/menuAddTitle"/>



</menu>






        view raw

        

          ActionBarMenu.xml

        

        hosted with ❤ by GitHub
      


and then in the Activity considered overriding OnCreateOptionsMenu method inflating ActionBar’s menu using created view:








  





public override bool OnCreateOptionsMenu(IMenu menu)



{



    MenuInflater.Inflate(Resource.Menu.ActionBarMenu, menu);



    return base.OnPrepareOptionsMenu(menu);



}






        view raw

        

          MainActivity_OnCreateOptionsMenu.cs

        

        hosted with ❤ by GitHub
      


We also need to define what happens when a menu option is selected. For that purpose, override OnOptionsItemSelected method:








  





public override bool OnOptionsItemSelected(IMenuItem item)



{



    if (item.ItemId == Resource.Id.menuAdd)



    {



        OpenAddingNewPerson();



        return true;



    }








    return base.OnOptionsItemSelected(item);



}






        view raw

        

          MainActivity_OnOptionsItemSelected.cs

        

        hosted with ❤ by GitHub
      


Next coding tasks
From now on you can watch my public Trello board, where I have all tasks to be done in the nearest future in MoneyBack defined. I will try to define deadlines for those tasks as well.
At the moment of writing this post, I’ve started adding a possibility to create Events. I will need to keep many-to-many relationship between Person and Event entities and I will probably use SQLite-Net Extensions library for that. You can expect a separate post about defining relationships using this library soon 
Other tasks left to be done
Apart from coding and developing the project, I still need to fulfill the DSP competition’s requirements. This is my 14th post within DajSiePoznac2017, so 6 posts still to be written. I have the ideas in my mind already and few next posts planned. There are only 3 weeks left to the end of the competition, so those days will need to be more intensive that it recently was, but that’s good, it means that you should be receiving more content here in the coming days and I will be spending more time on developing MoneyBack. Only positive changes, I hope 
Summary
We saw the status of MoneyBack project today. There are still many things to be done in the app to at least fulfill the minimal requirements I assumed in the beginning of the competition. but as I mentioned, the end of DSP is not the end of MoneyBack  On the other hand, DSP is a very good motivator, so I’ll try to make coming days and weeks more intensive. The most important goal for now is to fulfill the competition’s requirements for having 20 posts written until the end of May, which shouldn’t be problematic at all 
I’ve also published my Trello dashboard. You can find a link to it here.
Using this opportunity, I’d like to wish all DSP’17 participants good luck in the last weeks of the competition. I’m constantly reading the others’ blogs and I see a lot of very nice and decent quality stuff appearing in Polish programming community on your blogs and repositories – great job!
Keep your fingers crossed! 
The post MoneyBack – 3 weeks before the end of DSP appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/moneyback-3-weeks-before-the-end-of-dsp/feed/
			0
		
		
		2192	
		
		
		https://www.codejourney.net/android-apps-localization/
					https://www.codejourney.net/android-apps-localization/#comments
		
		
		Wed, 19 Apr 2017 20:48:55 +0000
				
		
		
		
		
		http://www.dsibinski.pl/?p=1803

					Hello everyone 🙂 As you might have noticed, I’ve recently decided to take a longer break in DSP competition. Few things to do, Easter in the meantime… but of course I didn’t give up and today I’m back 😉 In this post I’d like to show you how do we localize Android apps. Let’s see! What…

The post Android Apps Localization appeared first on CodeJourney.net.
]]>
										Hello everyone 🙂

As you might have noticed, I’ve recently decided to take a longer break in DSP competition. Few things to do, Easter in the meantime… but of course I didn’t give up and today I’m back 😉
In this post I’d like to show you how do we localize Android apps. Let’s see!


What is localization ?
Generally, localization is a process of adapting the product or application to specific markets by adjusting its language and cultural resources accordingly.
People often think that localization is only a process of translating documentation and user interface into multiple languages, but in fact it may concern many other not less important topics, e.g. formats of numeric values or dates, currencies, numbers comparison/sorting methods, symbols, national flags or even country-specific law requirements.
Android supports app’s resources localization in pretty easy way. We can quite conveniently provide different versions of strings, images and layouts used in our application for different languages/regions. Let’s take a look at the basics of Android app’s localization.
Android localization basics
In every Android application, localization is based on the language user has set on his/her device. The language can be changed in Settings -> Language & input. Changing the language in this place affects both user interface’s language and region-specific settings (e.g. dates formats).
To retrieve the current locale (constant/object representing selected language) in code the following statement can be used:
var currentLang = Resources.Configuration.Locale;
In case user has Polish language set on his/her phone, currentLang variable would contain “pl_PL” locale symbol. For the full list of locales symbols, see for example this list.
Basically, everything that is placed under Resources folder in Android solution can be localized. All of you probably have values folder in Resources, which contains Strings.xml file. We’ll see more details about this file in a while, but to present the ease of localization to you, it’s enough to create another folder under Resources called e.g. values-pl, which makes retrieving strings from Strings.xml file located in this folder on devices with language set to Polish. Simple as that. The same can be done with every type of resource. It means we can create totally different layouts of our Activities or use different images (e.g. countries’ flags) depending on user’s device’s language.
Strings localization
Strings.xml file
To-be-localized strings (BTW, I think that we should do it straightaway with all strings we use in our app) should be put in values/Strings.xml file, which has the following structure:








  





<?xml version="1.0" encoding="utf-8"?>



<resources>



    <string name="ApplicationName">MoneyBack</string>



    <string name="titleMenu">Menu:</string>



    <string name="btnPeople">People management</string>



    <string name="titleName">Name</string>



    <string name="titleLastName">Last name</string>



    <string name="titlePhoneNumber">Phone number</string>



    <string name="btnSavePerson">Save person</string>



    <string name="btnPeopleList">List of people</string>



    <string name="peopleListTitle">List of people</string>



</resources>






        view raw

        

          Strings.xml

        

        hosted with ❤ by GitHub
      


The file is built in accordance with standard XML rules. The name represents Android resource ID (cannot contain any spaces or dashes) to which we will refer from code and other places in order to retrieve the value of this resource, which is placed between “>” and “<” characters.
For instance, first resource from above-pasted Strings.xml has name = “ApplicationName” and value = “MoneyBack”.
As mentioned in the previous paragraph, I also created Strings.xml file in values-pl folder, containing the same resources’ Polish translations. The contents of values-pl/Strings.xml file:








  





<?xml version="1.0" encoding="utf-8"?>



<resources>



    <string name="ApplicationName">MoneyBack</string>



    <string name="titleMenu">Menu:</string>



    <string name="btnPeople">Zarządzaj osobami</string>



    <string name="titleName">Imię</string>



    <string name="titleLastName">Nazwisko</string>



    <string name="titlePhoneNumber">Numer telefonu</string>



    <string name="btnSavePerson">Zapisz osobę</string>



    <string name="btnPeopleList">Lista osób</string>



    <string name="peopleListTitle">Lista osób</string>



</resources>






        view raw

        

          Strings.xml

        

        hosted with ❤ by GitHub
      


Usage in layout files
In our Activities’ layout files (AXML) we can retrieve resources’ values by using @string/id syntax. For example, TextView‘s text can be set in the following way:








  





    <TextView



        android:text="@string/titleMenu"



        android:id="@+id/titleMenu" />






        view raw

        

          Main.axml

        

        hosted with ❤ by GitHub
      


It can be used exactly the same way in the UI designer in Visual Studio.
Usage directly in code
In the code we can retrieve values of particular resources using Resources.GetText method giving it selected resource’s id as Resource.String class’s property:
string titleMenuText = Resources.GetText(Resource.String.titleMenu);
With all strings translated, I can see UI of MoneyBack translated when my device’s language is set to Polish:




Quantity strings
Very interesting concept are so called quantity strings. It allows to define differently formatted strings depending on a number of some elements determined at runtime. For instance, on the list of people we could have the following strings displayed depending on the number of people:
“There is 1 person in your database.”
“There are 2 people in your database.”
To declare such kind of quantity string, we’d add to Strings.xml the following section:








  





<plurals name="numberOfPeople">



         <item quantity="one">There is %d person in your database.</item>



         <item quantity="other">There are %d people in your database..</item>



 </plurals>






        view raw

        

          Strings_plurals.xml

        

        hosted with ❤ by GitHub
      


To illustrate: in order to retrieve and format appropriate string depending on value stored in numPeople variable, the following code might be used:
var text = Resources.GetQuantityString(Resource.Plurals.numberOfPeople, numPeople, numPeople);
Second parameter passed is used to determine which string (plural) to use, and third parameter is the actual value passed to the final string (in the place of %d in that case).
The quantity of each plural can contain one of the following values:

zero
one
two
few
many
other

More details can be found here.
Application’s/Activity’s name
We can also localize the name of our app, by using string resource in the ActivityAttribute defined on MainActivity:
[Activity(Label = "@string/ApplicationName", MainLauncher = true, Icon = "@drawable/icon")]
The same can be done for any of our app’s activities. However, be careful here if you are referencing your main Android project from another one (e.g. from tests project) – I’ve experienced really annoying issue with that (more details below).
Other resources
As we already said, not only strings can be localized. You can localize any kind of resources placed within Resources folder, for example images or data files.
The file “obj\Debug\android\bin\packaged_resources” does not exist
Two weeks ago, when I finally decided to take a break in publishing DSP posts, I wanted to work on MoneyBack a bit, however I encountered very frustrating issue, which I even described in this StackOverflow post. I’ve been fighting with that problem for few days and I still actually don’t know the real cause of the issue.
Basically, when I used resource string on my PeopleListActivity in order to translate its title:
[Activity(Label = "@string/peopleListTitle")]
I couldn’t build my MoneyBack.Android.Tests (yes, different project!) project. I was getting the following build error message:

I explored all existing forums threads on this topic and couldn’t resolve this issue. Finally, by setting build output verbosity to Diagnostic in Tools -> Options -> Projects and Solutions -> Build and Run I was able to see the detailed error my build process is giving. It was telling me that @string/peopleListTitle doesn’t exist (or something similar). So when I changed the Label‘s value in ActivityAttribute to use a string directly (not taken as a resource), it worked fine and the build passed.
Today I tried once more to use resource string, obviously getting the same error message. Then I realized that my MoneyBack.Android.Tests project is referencing  MoneyBack project in which I define those somehow missing strings:

so I removed that reference (commenting out my unit tests which use MoneyBack‘s logic) and the build worked fine. Apparently when trying to build tests project, which references the main one, in which my strings are defined, it somehow needs those strings resources to be present in tests project’s output directory. I have no idea why, because I’m not directly using those strings resources in my tests project.
Then I added the reference back and in MoneyBack.Android.Tests project I just created values folder and copy-pasted Strings.xml file to it from the MoneyBack project:

and it builds OK!
Does any of you have some idea why it may happen? If you have a clue, you can answer here or even on SO.


For me it seems like a bug in the build process. I wanted to share it with you, because I wasted so much time because of this issue and maybe some of you will also find it useful.
BTW, I really recommend using Diagnostic verbosity of the build output for debugging such issues.
Summary
We’ve seen how Android application can be easily localized. I really recommend to put all strings visible for the end user from the beginning in Strings.xml file. Thanks to that, in case our application needs to be localized, we can even hire/ask some foreign languages’ interpreters to create country-specific values folder and translate strings resources conveniently. This is even very common in mobile apps communities, that people who are non-technical can contribute to the project by translating the application into their own language.
I hope I won’t meet any other issues like the one I described today on my further DSP way 🙂 It would allow me to write more stuff here and hopefully implement some usable app finally! Keep your fingers crossed 🙂
PS: If I already mentioned taking breaks in DSP competition, I will also take one more during the first week of May (1-5.05.2017). In case anyone cares 😉
 
 
The post Android Apps Localization appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/android-apps-localization/feed/
			12
		
		
		1803	
		
		
		https://www.codejourney.net/xamarin-android-intents/
					https://www.codejourney.net/xamarin-android-intents/#respond
		
		
		Sat, 01 Apr 2017 10:19:59 +0000
				
		
		
		
		
		http://www.dsibinski.pl/?p=1499

					We’ve already seen what are Activities, the most basic pieces of every Android app and today’s topic is associated with it. We’re going to see how to communicate between Activities (or Application Blocks) using Intents. Android Application Blocks Android apps are composed of Application Blocks, which are special kind of Android classes consisting several elements bundled together,…

The post Xamarin – Android Intents appeared first on CodeJourney.net.
]]>
										We’ve already seen what are Activities, the most basic pieces of every Android app and today’s topic is associated with it. We’re going to see how to communicate between Activities (or Application Blocks) using Intents.


Android Application Blocks
Android apps are composed of Application Blocks, which are special kind of Android classes consisting several elements bundled together, including:

Activities
Services
Resources (images, themes, classes)

Everything that comes in such package is coordinated by AndroidManifest.XML file. Especially, in this XML file (or by using various attributes on Activity class) it’s possible to register our Application Block to be “callable” by the others.
We’ll see more details in a while, but generally your app block is “callable” when it can be used by the other apps – probably you’ve already seen Application Chooser screen on your Android phone, e.g. when you wanted to open downloaded movie and the system asked you which video player you want to use. The same can be done with your own app – if you’re developing a dialer app, you can register it to be callable for ACTION_DIAL Activity Action. Then, as soon as any other app uses Intent to make a phone call (which we’ll see in this post), Application Chooser appears and your app will be one of the possible ones to use for making this phone call.
What is an Intent ?
Android system is designed to be loosely-coupled. Moreover, there is a principle of least privilege introduced in system’s architecture. It means that each app has access only to Blocks which it requires to work. Different Blocks don’t know much about each other (even if defined within the same application). Here’s where an Intent comes into play. Application Blocks use Intents to asynchronously communicate with each other.


In general, you can think of an Intent literally – it’s the intent (or a will) to do something. By sending Intents between different components, we can coordinate complex actions such as launching email app to send a message, using Location for obtaining user’s coordinates or navigating between application’s screens.
For me, we can think of Intents and their usage from two perspectives:

Intent as an intent – a will to do something. In this case, you use Intent to execute some action. When creating a new Intent you need to tell it what you want to do and give it necessary parameters for such operation (e.g. for send email action, you need to provide email address parameter)
Intent as a message – bidirectional information having sender, recipient and potentially some content. This can be for instance navigating to a new screen (Activity), where sender is the original Activity, recipient is the destination Activity to be opened and the content may consist some parameters to pass between two screens.

We’ll now see those two approaches in details.
Intent as an intent
In order to trigger another (external) action, e.g. camera recording or email sending, we can create an Intent and start a new Activity. Let’s see it by the example I implemented in MoneyBack – I added an additional ListActivity (PeopleListActivity class) which is the list of people added to app’s database. When a person on the list is clicked, I create an Intent in order to call his/her phone number as the following code presents:








  





  private void ListView_ItemClick(object sender, AdapterView.ItemClickEventArgs e)



  {



      var person = _peopleList[e.Position];








      var uri = Android.Net.Uri.Parse("tel:" + person.PhoneNumber);








      var intent = new Intent(Intent.ActionDial, uri);








      StartActivity(intent);



  }






        view raw

        

          PeopleListActivity_clicking.cs

        

        hosted with ❤ by GitHub
      


What those 4 lines of code do, is when tapping an entry from the list:

it opens the phone dialer app with selected person’s phone number to call:

NOTE: If I had more than one dialer app installed (if the other dialer app has itself registered as receiver for ACTION_DIAL, of course) Android would ask me to choose which app I want to use.

How did that happen? First actually interesting line of code is the following one:
var intent = new Intent(Intent.ActionDial, uri);
It creates a new Intent, giving to it – as we said in the previous paragraph – two things:

what we want to do – it this case, we set action to Intent.ActionDial, which corresponds to ACTION_DIAL Activity Action
operation’s parameters – in our case there is just one parameter, which is the phone number in URI format

For each type of Activity Action you want to trigger, you can find what parameters it needs in official Android Documentation.
In the end, we just need to finally start a new Activity with the Intent we just created:
StartActivity(intent);
and we’re all done.
Intent as a message
Now, let’s think about our app as a set of Activities, which are loosly-coopled. We have MainActivity class, which represents the main screen of our app. We’ve also built another Activity, which we want to open from the main one. In that case, we already see everything which fits into intent-as-a-message template – two Activities want to “talk” with each other.
In MoneyBack I changed the MainActivity to look as follows:

When clicking on “People Management” button, I’d like another Activity (represented by PeopleActivity class) to open.
In order to achieve that, MoneyBack executes the following code when clicking on the button:








  





  private void _btnPeople_Click(object sender, EventArgs e)



  {



      var intent = new Intent(this, typeof(PeopleActivity));



      StartActivity(intent);



  }






        view raw

        

          MainActivity_peopleManagementClick.cs

        

        hosted with ❤ by GitHub
      


What you can see here, is that we create a new Intent that takes two parameters:

Context – being the class storing information about current application’s/Activity’s state, from the place where the Intent is created; in our case, we set it to this, which is the calling Activity class reference. Context is our message’s sender
Type – this is our message’s recipient; in our case it’s the Type of destination Activity we want to start (PeopleActivity)

NOTE: Notice that we have no content provided in that case.

Then we just start the Activity as in the previous example and another screen appears:

If the back button is now pressed, it goes back to previous (calling) Activity. That’s how the Activities stack is built, by the way 
Passing additional content using Intent as a message
I mentioned we can also pass some additional data (message’s content) within an Intent. In the above example we didn’t do it, because there is no sense to pass anything from MainActivity to PeopleActivity for now. However, if we’d like to do that, we can add a simple modification to button’s pressing code in MainActivity:








  





  private void _btnPeople_Click(object sender, EventArgs e)



  {



      var intent = new Intent(this, typeof(PeopleActivity));








      var msgContent = "Hello! This is a secret sent from MainActivity! Don't tell anyone!";



      intent.PutExtra("secret_message", msgContent);








      StartActivity(intent);



  }






        view raw

        

          MainActivity_peopleManagementClick_msg.cs

        

        hosted with ❤ by GitHub
      


As you see, I used PutExtra method of the Intent class to insert msgContent into Intent’s simple key-value Bundle Dictionary called Extras, using “secret_message” string as a key. Then, in the destination Activity’s OnCreate method we can retrieve such value back using Intent.Extras.GetString (for String data type) method:

This kind of data-passing between Activities using Intent.Extras should be used only for simple, mostly key-value data transferring. There are other methods for passing/storing more complex data in an app or between different applications.
Summary
Today we’ve seen what is an Intent, how to use it to trigger external actions such as calling a phone number, sending email etc., but also how to use it to handle navigation between Activities. We’ve also passed key-value data between two Activities using Intent.Extras.
Intent, as well as Activity, is one of the fundamental concepts of Android. It’s essential to know how Intents work, how they relate to Activities, Services (which we’ll also cover one day) and Application Blocks.  I hope you’ll find it useful 
The post Xamarin – Android Intents appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/xamarin-android-intents/feed/
			0
		
		
		1499	
		
		
		https://www.codejourney.net/unit-testing-xamarin-application/
					https://www.codejourney.net/unit-testing-xamarin-application/#respond
		
		
		Sat, 25 Mar 2017 23:07:19 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=1166

					Today we’ll see how to add unit tests to Xamarin Android application, testing both platform-independent logic and Android-specific features. Issue with unit tests in Visual Studio 2017 When I started to create my data access methods in MoneyBack, I really wanted to start writing even some basic unit tests of that logic. My first trial was to…

The post Unit Testing Xamarin application appeared first on CodeJourney.net.
]]>
										Today we’ll see how to add unit tests to Xamarin Android application, testing both platform-independent logic and Android-specific features.


Issue with unit tests in Visual Studio 2017
When I started to create my data access methods in MoneyBack, I really wanted to start writing even some basic unit tests of that logic.
My first trial was to add a new project to my solution which contains unit tests. So I checked what kind of projects templates I have available and I I found Unit Test App (Android) project template and added it to my solution. Generated project contained TestsSample class with some unit-looking tests methods, but I had no idea how to execute them. With ReSharper installed, I didn’t have any “Run Tests” option on this project. I read somewhere on the web that this project type is used to execute tests on the device, but I couldn’t figure out how to do it. I gave up.
Then I found another project template – Class Library (Android) with nUnit. Sounds better, nUnit in the name suggests unit tests, so I added this project to my solution. This time when right-clicking the project I had “Run Tests” option, but when clicking on it I got the following exception coming from ReSharper:

“Hmm… Visual Studio 2017”, I thought. “Some bugs for sure”. And I…
… didn’t give up this time and with some help of folks from StackOverflow I figured out how unit tests should be done in Xamarin app. Let’s see that in the next chapters.
Levels of testing Xamarin application
There are basically three “levels” of testing Xamarin apps:

Classic unit tests of pure .NET/Mono

standard, good old unit tests of logic independent from targeting platform (Xamarin.Android/iOS/Windows Phone)
unit-testing frameworks can be used (nUnit / xUnit)


Platform-specific tests

unit tests of functionalities specific to targeting platform (e.g. Bluetooth, Location, GPS, SMS etc.)
specific for each platform
don’t contain GUI tests
executed on the emulator/device


UI tests

tests of UI elements of the app and how those react for input (touch) events
executed by cloud/testing lab services (local or remote)



We’ll dive into the first two, UI tests is more complex topic, which requires setting up tests lab or using cloud testing services. For small projects, in the beginning it’s not necessary.
Classic platform-independent unit tests
In order to simply use ReSharper for executing unit tests of logic, which is independent from Android/iOS/Windows Phone, there is a need to add a new project using template Unit Test Project (.NET Framework) to our Xamarin solution.
To such project, you can add your favourite unit-testing framework (such as nUnit or xUnit) by simply installing it from Nuget.  After, ReSharper allows to run your unit tests as in old good times:

The exception I was getting with ReSharper previously was because I added the project using template Class Library (Android) which has its target set to Android device/emulator. ReSharper doesn’t know about any Android-specific (or Xamarin-specific) testing, so it was displaying unhandled error.
Platform-specific unit tests
In order to test platform-specific (in out case Android-specific) functionalities of your application, the tests need targeting runtime environment to run. It means they need to be executed on the physical device or emulator. Providers of the most popular unit-testing frameworks created wrappers for on-device testing. I’m using NUnit Xamarin Runners.
First of all, a new project should be added to our solution. To make things easier, download NUnit Templates for Visual Studio (although it officially supports VS up to 2015, it also works in VS 2017) and install it. After, add new project using appropriate template – I chose NUnit 3 Test Project (Android). What’s interesting, the newly created project contains MainActivity class with the following content:








  





  public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsApplicationActivity



  {



      protected override void OnCreate(Bundle savedInstanceState)



      {



          base.OnCreate(savedInstanceState);








          global::Xamarin.Forms.Forms.Init(this, savedInstanceState);








          // This will load all tests within the current project



          var nunit = new NUnit.Runner.App();








          // If you want to add tests in another assembly



          //nunit.AddTestAssembly(typeof(MyTests).Assembly);








          // Do you want to automatically run tests when the app starts?



          nunit.AutoRun = true;








          LoadApplication(nunit);



      }



  }






        view raw

        

          MainActivity_Tests.cs

        

        hosted with ❤ by GitHub
      


As you can see, this is an Activity, so it will be launched as a separate app with its own GUI. It’s built using Xamarin.Forms. The comments in auto-generated class are obvious, so I won’t explain the details here. That’s just what nUnit wrapper for Android on-device tests does – it allows to be run as a separate, small application with a GUI allowing to run unit tests directly on the device (similarly to ReSharper tests runner we use directly in Visual Studio).
One testable piece of MoneyBack application is the Repository used for database operations (by the way I refactored and made it generic, you can see how it looks currently on GitHub), so I added RepositoryTests class to MoneyBack.Android.Tests project with two test methods:








  





[Test]



public void one_new_person_inserted_adds_one_new_row()



{



    // given



    var person = new Person()



    {



        Name = "A",



        LastName = "B"



    };








    var repo = new Repository<Person>(InMemorySqliteConnection);








    // when



    var numRows = repo.Insert(person).Result;








    // then



    Assert.AreEqual(1, numRows);



}








[Test]



public void new_person_added_has_id_primarykey_generated()



{



    // given



    var person1 = new Person



    {



        Name = "A",



        LastName = "B"



    };








    var person2 = new Person



    {



        Name = "A",



        LastName = "B"



    };








    var repo = new Repository<Person>(InMemorySqliteConnection);








    // when



    var n1 = repo.Insert(person1).Result; // getting Result in order to force Task's completion before continuing



    var n2 = repo.Insert(person2).Result;








    // then



    Assert.Greater(person1.Id, 0);



    Assert.AreEqual(person2.Id, person1.Id + 1);



}






        view raw

        

          RepositoryTests_methods.cs

        

        hosted with ❤ by GitHub
      


The interesting part is that as I’m using SQLite database in my app, I wanted to test it without creating database file on the device. For that purpose, when creating SQLiteAsyncConnection in order to initialize my Repository, I passed to its constructor a “:memory:” string, which makes SQLite database created in-memory (there is no physical file created):








  





  public SQLiteAsyncConnection InMemorySqliteConnection;








  [OneTimeSetUp]



  public void Init()



  {



      InMemorySqliteConnection = new SQLiteAsyncConnection(":memory:");



  }






        view raw

        

          RepositoryTests_sqlite.cs

        

        hosted with ❤ by GitHub
      


 
Such database lives in device’s memory only for the time of our unit tests.
After having tests written, there’s a time to execute them. As the project contains MainActivity class, we simply deploy and run it on a device/emulator, which presents the following view:

If any of our tests is not passed, we can see the failure’s details:

We can of course debug our units tests in Visual Studio. The GUI on the device also allows to re-run the tests and see results of all of them.
Summary
We’ve seen how to add two new projects to Xamarin solution: one containing platform-independent unit tests (old good ones), the other one testing Android-specific stuff which is run directly on the device or emulator.
For bigger and more “real” apps, UI testing would also be necessary. This however requires using some cloud testing lab or setting up your own testing environment. More details can be found here.
If you have any experience in testing Xamarin applications, share your insights/advices 
 
 
The post Unit Testing Xamarin application appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/unit-testing-xamarin-application/feed/
			0
		
		
		1166	
		
		
		https://www.codejourney.net/using-sqlite-database-in-xamarin-android/
					https://www.codejourney.net/using-sqlite-database-in-xamarin-android/#comments
		
		
		Sun, 19 Mar 2017 22:32:29 +0000
				
		
		
		
		
		
		http://www.dsibinski.pl/?p=970

					I started to define development tasks to be done within MoneyBack project in the coming days (maybe I’ll even publish my Trello board soon 🙂 ) and it turned out that each functionality the app is going to offer needs persistent storage (e.g. to store people, payments, events etc.). The obvious choice is the local database in which…

The post Using SQLite database in Xamarin.Android appeared first on CodeJourney.net.
]]>
										I started to define development tasks to be done within MoneyBack project in the coming days (maybe I’ll even publish my Trello board soon  ) and it turned out that each functionality the app is going to offer needs persistent storage (e.g. to store people, payments, events etc.). The obvious choice is the local database in which I could store my entities and application’s data.

In this post, I’d like to show you how quickly and easily SQLite database can be added and started to be used in Xamarin.Android project using SQLite.NET and Visual Studio 2017.


What is SQLite?
SQLite is an open-source database engine, which allows to store data in SQL structures. The whole database is stored in a single file, which makes it easily manageable on mobile devices. It’s lightweight, small and easily portable. It’s also prepared to work on multiple platforms.
There are some limitations in contrast to “classic” SQL database engines, including:

OUTER join syntax is not fully supported
for altering tables, only “RENAME” and “ADDCOLUMN” operations are available
writing to views is impossible (views are read-only).

SQLite database can be easily operated using SQLite.NET ORM library available to download and install via Nuget. Let’s see how to do it.
Installing SQLite.NET package
In order to install SQLite.NET package, simply open Android.Xamarin solution in Visual Studio, open Package Manager Console and type the following command:
install-package Sqlite-Net
After few seconds, two files are added to our project:

It means we’re all set 
Entity definition
We have SQLite ORM ready to use. Now we need to define our first entity. In case of MoneyBack, I decided to start with defining Person (plural: People) entity. First thing we need to do is to define entity class. I created “Entities” folder for that and added the following class file:








  





namespace MoneyBack.Entities



{



    [Table("People")]



    public class Person



    {



        [PrimaryKey, AutoIncrement]



        public int Id { get; set; }








        public string Name { get; set; }








        public string LastName { get; set; }








        public string PhoneNumber { get; set; }








        public string Email { get; set; }








        public override string ToString()



        {



            return $"[Person: Id={Id}, Name={Name}, LastName={LastName}, PhoneNumber={PhoneNumber}, Email={Email}]";



        }



    }



}






        view raw

        

          Person.cs

        

        hosted with ❤ by GitHub
      


Just a class, in which we define basic properties of a Person – Name, LastName, PhoneNumber and Email. As we are designing a database entities, we also need to have keys for each of them – in this case we add Id property, and decorate it with two attributes:

PrimaryKeyAttribute – marks the column as PRIMARY KEY
AutoIncrementAttribute – marks the column with AUTO_INCREMENT (unique number is generated when a new record is added into a table).

We also have TableAttribute defined on Person class. This attribute’s constructor takes a single argument name, which is the name of the table which will be created underneath. In our case, single entity is called Person, but the table should be named in plural (table == set of entities) so we want it to be called People.
I also implemented ToString() method in order to be able to easily see details of our entity if needed.
Location of database file
Before database can be used, a database file must be created on the device. ORM does it for us before any query is made on the database, but we need to specify where we want to keep the db file. On Android, it can be stored either on internal or external storage.
I created Constants.cs class in which I put a read-only constant string returning path to database file. As a folder to store db file, I used Environment.GetFolderPath(Environment.SpecialFolder.Personal) which returns local path defined in Android system’s environmental variable $HOME:








  





public class Constants



{



    public static readonly string DbFilePath = 



        Path.Combine(



                Environment.GetFolderPath(Environment.SpecialFolder.Personal), 



                "moneyback.db"



        );



}






        view raw

        

          Constants_dbPath.cs

        

        hosted with ❤ by GitHub
      


Database access methods
As soon as we have entity class defined and location of database file, we can start performing operations on the db – define tables, add new entities (rows), retrieve rows from the database, delete them etc. In general, it comes down to creating SQLiteConnection object and performing operations on it.
There are several approaches of exposing Data Access Layer services/methods – we can create a database service, entities repository or use complex services location and dependency injection in order to operate our persistent data. I don’t know what is a standard way in Android applications, but I decided to create a very simple repository for our Person entity and expose database-access methods in it:








  





public class PeopleRepository



{



    private SQLiteConnection db = null;



    protected static PeopleRepository me;








    static PeopleRepository()



    {



        me = new PeopleRepository();



    }








    protected PeopleRepository()



    {



        db = new SQLiteConnection(Constants.DbFilePath);



        db.CreateTable<Person>();



    }








    public static int SavePerson(Person person)



    {



        me.db.Insert(person);



        return person.Id;



    }








    public static Person GetPerson(int id)



    {



        return me.db.Get<Person>(p => p.Id == id);



    }



}






        view raw

        

          PeopleRepository.cs

        

        hosted with ❤ by GitHub
      


I haven’t even created any abstract layer for the repository (e.g. interface), as I simply don’t know what approach I will use for the next entities. I’m not sure if the repository is the right choice. On the other hand, I don’t think such rather simple app requires something more. What do you think ?


As you can see, PeopleRepository executes its static constructor when any of static methods is called for the first time, in which it instantiates db variable of type SQLiteConnection, giving it the path to db file we defined. If database file doesn’t exist, it will be automatically created. Then, db.CreateTable<Person>() creates People table if it doesn’t exist, according to what we defined in Person entity model.
Two static methods – SavePerson and GetPerson allow to save and retrieve Person entity to/from the database accordingly. The first one is additionally returning the integer Id of newly added row.
Usage in the code
I added two text fields to MoneyBack app to enter name and last name of person to be added and one button which actually allows to perform saving operation:

On clicking the button, the following method is executed:








  





private void _btnAddPerson_Click(object sender, EventArgs e)



{



    var name = _inputName.Text;



    var lastName = _inputLastName.Text;








    var id = PeopleRepository.SavePerson(new Person



    {



        Name = name,



        LastName = lastName



    });








    var person = PeopleRepository.GetPerson(id);








    if (person == null)



        Toast.MakeText(this, $"Person: Name={name}, LastName={lastName} wasn't properly saved!", ToastLength.Long).Show();



    else



        Toast.MakeText(this, $"Person saved, details: {person}", ToastLength.Long).Show();








}






        view raw

        

          addPersonButtonClick.cs

        

        hosted with ❤ by GitHub
      


 
Here’s the result of clicking the button in the app:

As you can see, in the toast message received, Id of the Person added has value 3. That’s because when I launched the app previously I’ve already added two new people. It shows that the data is really persistently stored and doesn’t disappear when the app is restarted.
Summary
Today we’ve seen that using SQLite file database in Xamarin.Android is very easy. Thanks to SQLite.NET lightweight ORM library we were able to quickly start working with the db.
To make the code ready for “production” use, I should also make it thread-safe (more details e.g. here) and add unit tests (which I’m BTW not able to do for now, I’m getting TargetInvocationException when trying to run any NUnit tests adding Unit Test App (Android) project in VS 2017…).
I’m also not sure if repository is a proper concept for managing local db entities in Android project. If you have more experience, I’d be grateful to hear how it should be done in a really “Android way” 
The post Using SQLite database in Xamarin.Android appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/using-sqlite-database-in-xamarin-android/feed/
			7
		
		
		970	
		
		
		https://www.codejourney.net/solving-performance-issues-with-dottrace/
					https://www.codejourney.net/solving-performance-issues-with-dottrace/#comments
		
		
		Sun, 12 Mar 2017 14:40:24 +0000
				
		
		
		
		
		http://www.dsibinski.pl/?p=728

					If you’ve ever had any performance issues with your .NET applications, you may find this writing interesting. In this post I’d like to present to you a tool produced by JetBrains – dotTrace, showing how using only one of its functionalities can help in finding causes of performance issues in .NET applications. Performance issue on production Months…

The post Solving performance issues with dotTrace appeared first on CodeJourney.net.
]]>
										If you’ve ever had any performance issues with your .NET applications, you may find this writing interesting.

In this post I’d like to present to you a tool produced by JetBrains – dotTrace, showing how using only one of its functionalities can help in finding causes of performance issues in .NET applications.


Performance issue on production
Months ago some of your colleagues implemented an application and delivered it to the Customer. The app is “Countries and Cities Manager”, which is used by some administrator working in local government unit. That’s how it looks:

That’s cool, isn’t it ? This “administration panel” allows to add a new city to the country. User fills name of the city and provides ISO code of the country considered. You may think “who would ever use it and for what?”. True. But first of all, this is just an example  , and secondly, imagine that Russia annexes some big European country. What happens then ? User administrating local government system must use your manager application to insert hundreds or thousands of new cities in Russia. Gotcha!
The next day you receive a ticket in your company’s issues tracking system. Taking into consideration that an average number of cities in east-European countries is ~600, the ticket’s priority is set to “Blocking”. The description of the issue is:

User fills the “City” and “Country ISO Code”, clicks “Add city”
Waits for 10 seconds…
Waits for 20 seconds…
Waits for 30 seconds…
Error message received:



User corrects “RU” to “RUS”
 

Waits for 10 seconds…
Waits for 20 seconds…
Waits for 30 seconds…
 City added!
Scenario repeats for each new city to be added. Performance is unacceptable.

Initially you have no idea what could be the reason. Such simple operation and such terrible performance? Let’s see…
Looking for issue with dotTrace profiling
In such cases, especially if I don’t know the code of the application considered, the very first thing I do it to use dotTrace in order to profile the application when executing bad-performance actions. It provides many features, including:

detecting performance bottlenecks in .NET applications
getting information about calls execution times
analyzing calls order on a timeline
profilling SQL queries and HTTP requests
profiling unit tests
… and many more.

We will use only the simplest profiling mode which is called Sampling.
After you downloaded and installed dotTrace, launch the application you want to profile first. Then, launch dotTrace and in Attach to Process section find and select process of your app and select Sampling mode:

Then, click “Run” button just below Sampling mode selection – you’ll see the profiling session has started:

Next, go to your application and execute bad-performance action. In our case, we click on “Add city” button:

App is not responding – cool! Now we wait those 10, 20, 30 seconds until we get the error message described by the user. To be sure what’s happening, we can click the button few more times (maybe the next executions are better?). I clicked it 3 times are the times were pretty the same.
That’s the end of our bad-performance action, so in dotTrace session’s window click “Get Snapshot and Wait”:

After few seconds, JetBrains dotTrace Performance Viewer opens. Open “Threads Tree” on “All Calls” tab:

In this section we normally see all the threads running within our application during profiling time. We had only one thread, so let’s expand the details to see the time and percentage duration of particular calls from the calls stack:

At this moment, without even opening the code, we already see that method called GetAllEuropeanCountries takes 83.63% of our thread’s execution time. What’s more, we can see that this method is defined in CountriesCitiesDbService which apperently retrieves list of European countries from the database or some external source.
The most percipient of you probably noticed there is Thread.Sleep(Int32) method called one level down – yes, that’s for example’s purposes  , but in real world this would be a database query or a web service call here. The most important is that we know what takes the longest during our operation. Let’s now fix it!
Fixing the issue
Let’s open CountriesCitiesManager solution and use the knowledge we already have from the profiling. We go to the AddNewCity(String, String) method, in which the method for getting countries was called (this is deductible from the calls tree in performance viewer). Here’s the code:








  





private bool AddNewCity(string cityName, string countryIso)



{



    var city = CountriesCitiesDbService.GetNewCity();



    var europeanCountries = CountriesCitiesDbService.GetAllEuropeanCountries();



    var country = europeanCountries.FirstOrDefault(ec => ec.IsoCode.Equals(countryIso));








    if (country == null)



        throw new ArgumentException($"Country with ISO Code {countryIso} does not exist!");








    city.Name = cityName;



    city.Country = country;








    CountriesCitiesDbService.SaveCity(city);



    return true;








}






        view raw

        

          AddNewCity.cs

        

        hosted with ❤ by GitHub
      


AddNewCity method is called every time the “Add city” button is pressed. In line number 4. we are getting the list of all 46 European countries:

How probable it is that the number of countries in Europe changes during our application’s runtime? Very close to 0, I’d say. So there is totally no sense in retrieving the list of EU countries (from the DB, web service or whatever) every time the button is clicked!


We need to cache this list somehow. Let’s simply extract the variable for storing EU countries as read-only class property initialized only when used for the first time:








  





private List<Country> _europeanCountries;








public List<Country> EuropeanCountries => 



    _europeanCountries ?? (_europeanCountries = CountriesCitiesDbService.GetAllEuropeanCountries());






        view raw

        

          EuropeanCitiesProperty.cs

        

        hosted with ❤ by GitHub
      


and use it in AddNewCity method:








  





private bool AddNewCity(string cityName, string countryIso)



{



    var city = CountriesCitiesDbService.GetNewCity();








    var country = EuropeanCountries.FirstOrDefault(ec => ec.IsoCode.Equals(countryIso));



    // the rest of method's code…



}






        view raw

        

          AddNewCity_Corrected.cs

        

        hosted with ❤ by GitHub
      


When the application is now launched, sampling started and button clicked 3 times, we already see the improvement:

AddNewCity takes 65.96% now. This is average value from all the calls we made, so let’s now perform sampling starting from the 2nd click:

The whole AddNewCity method is now taking only 0.41% of the calls during the operation.
Now, if we want to make Customer’s life beautiful, we’d extract initialization of EU countries list to another thread, so it can happen when the application launches and UI is not frozen. We will however stop here. You get the idea, don’t you ? 
Summary
Today we’ve seen how easily – by performing just the simplest profiling session that can be done in dotTrace – it may be to detect what causes real performance issues in .NET application. Of course the example was pretty naive and simple, but I didn’t make it up – many times I’ve already worked with performance issues in production code which were caused by retrieving so called “dictionary” or static data using some API or database connection every time in a loop or repetitive process, which was totally unnecessary. By only implementing some kind of cache (maybe a bit more reasonable than the one we did, which in our case was actually enough), I managed to optimize processes executing time from 3 or 4 hours to several seconds.
Obviously if you’re an experienced developer, you’d probably identify such places in which caching or similar mechanism should be used when writing code. Profiling may however be useful for less experienced programmers or when working with legacy code we didn’t write (or we wrote months or years ago  ). It doesn’t cost much, except the cost of dotTrace itself, which is a part of ReSharper Ultimate, but this tool is just an example, you are not limited to it. For sure there are many other tools that offer the same (or maybe even more?) functionalities.
What are the tools you use for debugging performance issues ? Maybe you also use dotTrace, but can share some experience in using its other functionalities?
The post Solving performance issues with dotTrace appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/solving-performance-issues-with-dottrace/feed/
			3
		
		
		728	
		
		
		https://www.codejourney.net/xamarin-android-activities/
					https://www.codejourney.net/xamarin-android-activities/#comments
		
		
		Sat, 11 Mar 2017 18:53:10 +0000
				
		
		
		
		
		http://www.dsibinski.pl/?p=405

					Today we’re going to take a look at Android’s most basic and in the same time most important concept, which is an Activity. To create even the simplest “HelloWorld” app one should know what are the Activities and how to work with them. What is an Activity ? The simplest, an Activity is a single…

The post Xamarin – Android Activities appeared first on CodeJourney.net.
]]>
										Today we’re going to take a look at Android’s most basic and in the same time most important concept, which is an Activity. To create even the simplest “HelloWorld” app one should know what are the Activities and how to work with them.


What is an Activity ?
The simplest, an Activity is a single screen in Android application. The concept of Activities is unusual in programming and it’s specific to Android platform.
Every Activity in Xamarin consists of two components:

UI (XML) – layout with user controls defined
Code (C#) – implementing the behavior

Let’s consider email client application – it’d probably have several Activities: “New email”, “List of emails”, “Email details”, “Settings” – notice all of them having both UI and behavior. We’d probably need “Email sending service”, which doesn’t necessarily need UI, so it wouldn’t be created as an Activity, but rather as a separate class realizing concrete task.
As we can already see, every Android app contains several Activities:

In most programming platforms, the application has a static method which is called on the application’s startup. This is not the case in Android – do you remember our MainActivity class from the previous post ? It’s decorated with ActivityAttribute which registers the Activity within the Android system, but what’s more important by having MainLauncher attribute’s property set to true it tells the system it’s the startup Activity for the application within which it’s registered. It means nothing more than when our app is launched, Android creates MainActivity as the first one from all Activities in our application. Apart from that, OS operates the MainActivity as all other Activities.
Activities Back Stack
Android app starts its own Activities from other Activities. It may also start Activities that are defined by different apps, e.g. your Android app can offer a possibility to send an email. You don’t have to implement your own email sending client for that – it’s possible to use already existing email sending Activities (using Android Intents, which we’ll also cover one day) registered within another apps installed in the system which expose such “external calling” possibility. Then, this external app launches looking as if it was the part of your application. This is very powerful!
When your email is finally sent, you are redirected back to your app from which you triggered email’s sending. How is that possible?


In order to ensure such way of functioning, Android keeps all the Activities needed to perform a certain job (even if they come from different apps) in the same task. The “scope” of a task (when new task is created, what Activities it contains etc.) depends, among others, on Android version (e.g. starting from Android 7.0 many apps can be started in multiple windows in the same time on a single screen – in that case, the system keeps a separate task for each window).
Within a particular task, several Activities are started. Each started Activity is pushed to the Activities Back Stack. The Activity being on the top of the stack has focus (is visible to the user). The previous Activities remain on the stack, but are stopped or even destroyed by Android system in certain cases (few more words about it in the next chapter).
Activities Back Stack is a LIFO objects structure: when user presses Back button the current Activity is popped from the top of the stack and the state of the previous Activity is restored. The following figure visualizes this behavior:

Android Activities Lifecycle
We already know the Activities are kept on Back Stack. We also need to know that Android OS may try to restart the application (after it crashed, for instance) at the last opened Activity. The OS may also pause the Activities when they’re not active or kill them when the device is low on memory. All those possible operations and states’ changes form Android Activities Lifecycle, which is a set of defined states in which every Activity may be:

Let’s see what those states mean:

Running – Activity is in the foreground (top of the activities stack); highest-priority Activity for OS
Paused – Activity is in this state when still visible, but covered by another non-full sized Activity or when the device enters sleep mode; second-highest-priority Activity for OS
Backgrounded/Stopped– Activity enters Backgrounded state when it’s overtaken by another, completely new Activity which is pushed on the top of the back stack; lowest-priority Activity for OS, which will be killed firstly in order to free resources
Restarted – this state is not visible on the diagram, however it’s possible that Android (e.g. user using task manager or similar app) kills the app being in any of above-mentioned states; if the user wants to go back to this Activity later, it must be restarted (previous state must be retrieved).

Handling states changes – lifecycle methods
Android (and Xamarin) provides SDK methods that are called by the OS each time an Activity’s state changes. Those methods may be overridden and implemented for each Activity in order to react on states changes and ensure application’s stability. The following diagram visualizes the dependencies and flow of methods being called:

Let’s see in what cases the particular methods should be implemented:

OnCreate() – called when an Activity is created; used for initializing views and variables
OnStart() – called immediately after OnCreate() finishes; UI refreshing can be handled here
OnResume() – called after OnStart() finishes and also when Activity is restarted after being paused
OnPause() – called when OS is about to pause or move the Activity to the background; here all resources-consuming objects should be cleaned-up, unsaved changes should be stored in some kind of persistent storage to be able to restore it when the Activity is revealed
OnStop() – called when the Activity stops being visible to the user or is destroyed (e.g. when OS needs to release some resources)
OnDestroy() – final method called on Activity just before it’s destroyed; it may not be called in some cases, so it’s better to clean-up resources in OnPause() and OnStop() methods.

Let’s see some code
In order to really test those lifecycle methods, I added a stunning functionality to MoneyBack app:

As you could already realize, you can enter amount of money spent, number of people involved and it will make a simple division operation to split the costs equally. That’s already kinda costs splitting, right ?! 
I implemented the lifecycle-control methods to check how it really behaves.
OnCreate








  





protected override void OnCreate(Bundle bundle)



{



    base.OnCreate(bundle);








    // Set our view from the "main" layout resource



    SetContentView(Resource.Layout.Main);








    _amount = 0.00m;



    _result = 0.00m;



    _numberOfPeople = 0;








    InitializeUserControls();



}








// …








private void InitializeUserControls()



{



    _inputAmount = this.FindViewById<EditText>(Resource.Id.inputAmount);



    _inputNumberOfPeople = this.FindViewById<EditText>(Resource.Id.inputNumberOfPeople);



    _txtResultDecimal = this.FindViewById<EditText>(Resource.Id.txtResultDecimal);



    _btnCalculate = this.FindViewById<Button>(Resource.Id.btnCalculate);



}






        view raw

        

          MainActivity_OnCreate.cs

        

        hosted with ❤ by GitHub
      


Here I only initialize my view from layout, Activity’s private variables and instantiate user controls. Nothing more for this simple example.
OnStart








  





protected override void OnStart()



{



    base.OnStart();



    RefreshUserInputsFromVariables();



}



// …



private void RefreshUserInputsFromVariables()



{



    _inputAmount.SetText(_amount.ToString(CultureInfo.InvariantCulture), TextView.BufferType.Editable);



    _txtResultDecimal.SetText(_result.ToString(CultureInfo.InvariantCulture), TextView.BufferType.Editable);



    _inputNumberOfPeople.SetText(_numberOfPeople.ToString(CultureInfo.InvariantCulture),



        TextView.BufferType.Editable);



}






        view raw

        

          MainActivity_OnStart.cs

        

        hosted with ❤ by GitHub
      


In OnStart() method I just refresh UI elements – in that case initialize their Text properties with values stored in private variables.
OnResume








  





protected override void OnResume()



{



    base.OnResume();



    InitializeUserControlsEvents();



    // TODO: retrieving variables (amount, number of people) from persistent storage (file, database)



}








// …



private void InitializeUserControlsEvents()



{



    _btnCalculate.Click += _btnCalculate_Click;



}






        view raw

        

          MainActivity_OnResume.cs

        

        hosted with ❤ by GitHub
      


As we know, OnResume method is called every time our Activity is brought to the top of Activities stack (either after OnCreate -> OnStart or when revealing it after being backgrounded). That’s a very good place to initialize dependencies to external services (e.g. open communication with DB or remote service). In my case, I just subscribed to Click events of the button. If I had any persistent storage present (for instance local DB) I would in this place retrieve recently saved values from it to my Activity’s variables to restore its state (OnResume might be called when Activity class’s state is already cleaned up).
OnPause








  





protected override void OnPause()



{



    base.OnPause();



    DetatchUserControlsEvents();



    // TODO: saving variables (amount, number of people) to persistent storage (file, database)



}



// …



private void DetatchUserControlsEvents()



{



    _btnCalculate.Click -= _btnCalculate_Click;



}






        view raw

        

          MainActivity_OnPause.cs

        

        hosted with ❤ by GitHub
      


In OnPause method I need to be consistent with what I do in OnResume – when my app is taken to the background, I don’t need to wait for my button’s click events anymore, so let’s detach from it (maybe button’s Click event is not the best example here, but it’s just to visualize the purpose of the method). When my app is resumed, we will subscribe to this event again. Again, if I had any persistent storage, I’d save all variables’ (which are necessary for restoring Activity’s state) values here to this storage, so they are able to be retrieved back as soon as OnResume is called.
OnStop & OnDestroy
I didn’t implement those two methods in my app, it’s too simple to need anything in those places.
I deployed the app, attached with debugger and checked the order of methods’ calls – all of them were called as described in previous paragraph.
Summary
It’s vital to understand how Android Activities and their states work. Even though it seems to be Android-specific, I’d rather say such approach is reasonable and even required by hardware on which mobile apps run (BTW, similar states seem to exist in iOS apps).
When building Android app we need to think about Activities, especially make sure that each Activity in our application properly implements necessary lifecycle methods.
Do you have or know any best practices while working with Activities and managing their lifecycle? I’d appreciate if you share it in the comments 
 
 
 
The post Xamarin – Android Activities appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/xamarin-android-activities/feed/
			3
		
		
		405	
		
		
		https://www.codejourney.net/hello-xamarin-world-first-steps/
					https://www.codejourney.net/hello-xamarin-world-first-steps/#respond
		
		
		Sat, 04 Mar 2017 23:12:14 +0000
				
		
		
		
		
		http://www.dsibinski.pl/?p=244

					This time I want to say “Hello” to Xamarin world. First thing that needs to be done before starting Xamarin development, is obviously the installation of all necessary components. In this post I want to share my feelings about the installation (not without issues of course), configuration of my Xamarin Android solution and deployment process to…

The post Hello Xamarin World – first steps appeared first on CodeJourney.net.
]]>
										This time I want to say “Hello” to Xamarin world.

First thing that needs to be done before starting Xamarin development, is obviously the installation of all necessary components.
In this post I want to share my feelings about the installation (not without issues of course), configuration of my Xamarin Android solution and deployment process to the device.


Xamarin installation into Visual Studio 2015
I’ve created my account at xamarin.com, logged in and chose Download Xamarin for free to download the installation package. There are generally two IDEs that can be used for Xamarin development: Visual Studio or Xamarin Studio. I’ve already had VS 2015 installed and decided I don’t want to explore a new IDE, so I downloaded installer for Visual Studio. What’s more, following Xamarin’s website, “Xamarin Studio is no longer included” in the Windows installer and they “encourage Windows developers to move to Visual Studio”. Well, that’s understandable, Microsoft acquired Xamarin, didn’t they? 😉
BTW, when downloading Xamarin I was obliged to fill the “Company” field – does anyone know why is that?
 Android SDK and emulator images size
Interesting parts of the installation (if there could by any at all?) are Android Emulator installation which is then integrated into Visual Studio as well as Android SDK installation – fortunately it’s possible to change the location of Android SDK installation, because right after the setup it takes an enormous amount of disk space (with mandatory tools mentioned in the installation guide and two Android APIs):

I’ve examined a bit more and it turns out that system images take the most of this space. Those are used only by emulators to be able to create a virtual device and debug on a simulator instead of deploying the app to a physical device every rime.
When I used to write some Android apps in Java and Android Studio long time ago, I found it very hard and complex to debug/test anything using emulator – it was simply very, very slow to load and work. This time I’ll see if emulator built in Visual Studio will do the job – if yes, why not using it ? I will of course also deploy directly to the device for tests, but it also takes time. I remember that when I wanted to test some small adjustments done “on the fly” (e.g. UI modifications/alignments) I dreamt about doing it quicker then deploying app to the phone every time. We’ll see, if emulator won’t do the job – I will clean up those folders.
 First issue in DSP
I had to create a separate paragraph for that 🙂 Of course, it must have finally happened – first issue on my DSP way! Installation error, of course – “Installation of ‘Xamarin’ failed with more then one exception (attempt 3). It was not possible to complete an automatic installation.”


I expected the installation to terminate and evening spent on looking for a solution, exploring StackOverflow threads, but to my surprise a quite familiar-looking screen appeared explaining what to do next, i.e. how to install all the components manually. I had to download and install Java JDK, Android SDK and Xamarin.
After the next 30 minutes everything seemed to be installed. Just two last configuration steps in Visual Studio as described here. Finally, to be able to run Android emulator Android Virtual Device Manager needs to be configured, as this tutorial describes.
Android Solution Creation
I cloned my Git repository, opened Visual Studio and created MoneyBack solution 😉 I chose the project of type Blank App (Android). Here’s what VS produced:

Android Xamarin solution contains the following elements out-of-the-box:

Properties – here AssemblyInfo.cs is probably well-known to all .NET developers (for the others: this file is .NET assembly’s metadata file, containing basic data about our application, like its name, version, company etc.), but there is also AndroidManifest.xml, which contains details and requirements for Android application, e.g. app’s name, supported SDKs versions numbers and required permissions for which the end user is asked when installing the app
References – contains other assemblies required for the application to build; in case of Xamarin Android solution, it references both .NET assemblies like System or System.Core and Mono.Android assembly
Components – stores Xamarin development packages that can be retrieved from Components Store (something like Xamarin-specific Nuget, I guess 😉 )
Assets – allows to store additional files needed by the app (e.g. text files) available easily from the code
Resources – contains strings, images and layouts of the application

MainActivity
Apart from above-mentioned folders, solution contains an Activity class (MainActivity.cs) which is decorated with ActivityAttribute:
[Activity(Label = "MoneyBack", MainLauncher = true, Icon = "@drawable/icon")]
We’ll get into details of activities soon. For now, let’s just assume that:
MainLauncher = true
means that this class is the starting point of the application. It contains only one method:
protected override void OnCreate(Bundle bundle)
{
   base.OnCreate(bundle);

   // Set our view from the "main" layout resource
   SetContentView (Resource.Layout.Main);

}
Again, we’ll dive into Android activity’s lifecycle very soon, but we can already imagine that “OnCreate” method is called when the activity is created.
MoneyBack on the phone
I plugged my Huawei P8 to the laptop, hit F5 and hoped to see my app running on the device. Instead, two components were installed first as separate apps – Mono Shared Runtime and Xamarin.Android API-25. Those two are used in debug build mode to allow debugging stuff. It would be fine if I didn’t have to re-plug my phone after installation of each of these two, as phone was doing nothing after.
 Finally,  MoneyBack appeared on Huawei’s screen with sad, black empty canvas. I added some well-known sentence to become a real Xamarin-newbie:

MoneyBack on the emulator
I couldn’t initially manage to deploy my application to Android Emulator device. I tried creating few emulator devices – firstly I had issues with very strange resolution on the emulated device, then I created another one and when I tried to deploy on it I got an error saying “2>Emulator is not ready to be used”. What I came up to is creating new Android Emulator Device, trying to start it (without deployment) and having “android” text on the device’s screen for the last 20 minutes. Then I found this emulation acceleration guide, so I installed HAXM and it helped A LOT. Emulator is now starting within 30 seconds and I managed to deploy my app on it. Cool.
Summary
Automatic installation of Xamarin on Windows with Visual Studio didn’t work, so I had to install all the packages manually, however it wasn’t problematic. Deployment to the phone was OK, but the installation of two additional components (Mono Shared Runtime and Xamarin.Android API) forced me to re-plug the device twice. I hope I won’t have this case very often, because if every deployment looks like that I’ll never finish this app…
I recommend everyone who wants to work with Android device emulator installing HAXM – it really boosts the emulation.



Get ready for a deep dive into Xamarin soon 😎



 
The post Hello Xamarin World – first steps appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/hello-xamarin-world-first-steps/feed/
			0
		
		
		244	
		
		
		https://www.codejourney.net/windows-services-using-topshelf/
					https://www.codejourney.net/windows-services-using-topshelf/#respond
		
		
		Sat, 14 May 2016 18:19:52 +0000
				
		
		
		
		http://www.dsibinski.pl/?p=26

					Hello again 🙂 Visibly this is going to be my first technical post here. I hope you’ll find it useful. Windows Services Recently I came up with a need to create an application, which executes some tasks in the background based on file system’s events. “That’s easy”, one would say. “Build Windows Service app”, he…

The post Building Windows Services using Topshelf appeared first on CodeJourney.net.
]]>
										Hello again 🙂

Visibly this is going to be my first technical post here. I hope you’ll find it useful.


Windows Services
Recently I came up with a need to create an application, which executes some tasks in the background based on file system’s events. “That’s easy”, one would say. “Build Windows Service app”, he would add. Sure, that was also my first idea.
I think that’s very common that we want to create an application without any GUI, which purpose is just to do something in the background. Moreover we’d like it to be independent from the user running it – we want it to be running all the time, without having to manually launch it – especially when the application is running on customer’s environment, where we can’t be logged in all the time running the application.
Here comes the service – long-running executable with no user interface, which runs in its own Windows session. Such application can be:

executed by any user created in the system (e.g. with specific security policies assigned),
started automatically when the system launches,
automatically restarted in case of errors,
at any time started, paused, stopped or restarted.

Even if you’ve never developed any service applications, you are using many of them – check your services.msc to see the list of services currently running in your system.
Topshelf
Visual Studio 2015 provides a template to create Windows Service application and probably I could finish my post here. However, I would like to share with you an even easier way of building services: to do it with Topshelf – a very lightweight open-source library, which purpose it to make services development, debugging and deployment painless. Topshelf allows the developer to focus on service’s functionality, instead of wasting time interacting with .NET Framework’s build-in services support. There is also no more need to install your service using InstallUtil or learn how to attach your Visual Studio debugger to running service to detect issues.
Using Topshelf it’s enough to create console application, add one service class with public Start and Stop methods, configure service’s startup parameters (its name, display name, description etc.) and you’re ready to go. Below we’ll see how to do it.
Creating Windows Service application
After creating console application in Visual Studio, add Topshelf to the project by installing it from Nuget:

Adding service class
Then, create service class, which is responsible for executing your service’s logic:
class FileWatcherService
{
   public bool Start()
   {
      // Initialize your service application here
      return true;
   }


   public bool Stop()
   {
      // Executed when the service is stopped
      // Dispose your objects here etc.
      return true;
   }
}

Both of those methods return boolean to indicate that starting/stopping of the service completed successfully.
Adding service configuration
Now we only need to configure the service’s parameters. Topshelf provides HostFactory class which contains Run method, to which we can pass fluently-created set of settings:

service class instance,
methods to be executed while the service is started/stopped/paused/continued,
service’s name, display name, description,
start/stop timeouts,
startup type (automatic, manual, automatic delayed),
… and many more.

The set-up code should be put in the Main method of Program.cs. In our case, the simplest configuration could look as follows:
static void Main(string[] args)
{
    HostFactory.Run(serviceConfig =&amp;amp;amp;amp;gt;
    {
        serviceConfig.Service&amp;amp;amp;amp;lt;FileWatcherService&amp;amp;amp;amp;gt;(serviceInstance =&amp;amp;amp;amp;gt;
        {
            serviceInstance.ConstructUsing(() =&amp;amp;amp;amp;gt; new FileWatcherService());
            serviceInstance.WhenStarted(execute =&amp;amp;amp;amp;gt; execute.Start());
            serviceInstance.WhenStopped(execute =&amp;amp;amp;amp;gt; execute.Stop());
        });

        serviceConfig.SetServiceName("FileWatcherService");
        serviceConfig.SetDisplayName("File Watcher Service");
        serviceConfig.SetDescription("Service monitoring local folders for file system events");
        serviceConfig.StartAutomatically();

    });
}

Debugging the service
Ease of implementation and configuration of the service application isn’t the only benefit of using Topshelf. Our application has been created as a console app, so it can be simply run and debugged by using F5 button. No more need to attach debugger to the service itself 🙂
Installing the service
Topshelf also adds some “shell layer” to our application. To install executable file (which is the output of our console application) into Windows Service Control Manager (SCM) to be running as a “real” Windows Service, it’s enough to open the command line, navigate to the folder where the .exe file is present and install it passing install as .exe’s parameter (e.g.: FileWatcherService.exe install). After executing it, we can see our service created by looking into services.msc:


It’s similarly easy to uninstall the service.
Not only Windows
The official Topshelf’s project’s page says:

Topshelf works with Mono, making it possible to deploy services to Linux. The service installation features are currently Windows only, but others are working on creating native host environment support so that installation and management features are available as well.

So it’s the next great benefit of Topshelf to use applications built with it on Linux.
More
If you want to check what’s more that Topshelf can do, you can visit project’s official page, check it’s GitHub repository or watch this very good Pluralsight course.
Summary
Summing up, I found Topshelf very handy in developing service applications. One of the major pros of using it is ease of installation – it may become very important in the production environment, especially when dealing with any kind of distributed environment. Moreover, debugging the service as a console application makes fixing bugs quick and comfortable. I recommend everyone to use it in case of a need to write any service application.
The post Building Windows Services using Topshelf appeared first on CodeJourney.net.
]]>
					
					https://www.codejourney.net/windows-services-using-topshelf/feed/
			0
		
		
		26