Documents in Resco Mobile CRM (SharePoint, DropBox, Google Drive, OneDrive) – a technical deep dive – Part 4

documents_4_main

We’ve looked at the basic terminology and the presentation of documents in the app’s user interface in the first part of this series and continued with  document filtering, viewing, editing, storage and safety. Last week, we examined the details of how Resco Mobile CRM works with file hosting services (especially SharePoint). And now we’d like to wrap up our technical deep dive into document integration with a couple of final observations and tips for improving the app’s performance. Continue reading

Documents in MCRM (SharePoint, DropBox, Google Drive, OneDrive) – a technical deep dive – Part 3

documents_3_main

In today’s post, we will examine the details of how Resco Mobile CRM works with file hosting services. Continue reading

Documents in Resco Mobile CRM (SharePoint, DropBox, Google Drive, OneDrive) – a technical deep dive – Part 2

Documents_2_main

In Part 1 we’ve established the basic terminology when discussing the use of documents in Resco Mobile CRM and described how they’re presented in the apps user interface. In this post we’ll take a closer look at document filtering, viewing, editing, storage and safety. Continue reading

Documents in Resco Mobile CRM (SharePoint, DropBox, Google Drive & OneDrive) – a technical deep dive – Part 1

Document_deep_dive

In case you did not work with Mobile CRM documents yet, we suggest to start with an earlier blog that provides a high-level overview of how to utilize documents in the Resco Mobile CRM app. It was also the most read Resco blog post of 2016.

In this blog series, we will focus on how the app works with documents from a technical point of view. Continue reading

Mobile CRM limits: Performing an application test run

In the previous post titled Mobile CRM limits. Where are they?, we talked about things that limit the application; such as RAM, storage and Internet speed. If you haven’t read that post yet, we highly advise you to do so.

What we are going to do now is to give Resco Mobile CRM application a test run and investigate the database it created.

Desktop is the best platform for such experiments – all the tools are available for free and the file system is open. (Plus, there’s a security benefit: Your business data won’t be exposed to the public network.) Continue reading

Mobile CRM limits. Where are they?

While desktop Dynamics CRM installations make use of fast machines with (nearly) unlimited storage, mobile devices are severely limited in this respect.

You typically get numbers such as:

  • RAM Memory: ~1GB RAM (iPhone5/6, high end Android devices approach 3GB).
    Low RAM values (~500MB or less) will negatively impact the database speed or, for example, the download speed.*)
  • Storage memory: It’s here where the database will be located.**) Today’s mobile devices typically offer 4+ GB of storage memory, which is – by proper planning – enough. We’ll return to the subject later.
  • Speed: It is difficult to bring any generally applicable numbers. Instead, here are a few numbers that measure activities done by Resco MCRM:
    Database writes on a decent mobile device are 5-10x slower than the same operations done on a rather aging 2GHz W7 desktop. And it can go even worse, for example Xml parsing (used in communication with CRM server) is ~100x slower.***)
  • Internet speed: We cannot give any generally applicable statements here. Speed of 3G networks vary between 144kbps to 4+Mbps, 4G networks are even faster.****)

Continue reading

Synchronization pauses for about a minute saying “Sync: ServerDeletes”. Why?

Ok, everybody understands the concept of synchronization – server changes are applied to the client database and vice-versa the client changes are sent to the server. That’s the basic idea and even if I didn’t write it, you would certainly formulate it in a similar way.

I may similarly explain other related concepts; such as the connection, the conflict resolution etc. – you have an a priori idea of these things and that idea is usually correct.

However, the concept “synchronization of server deletes” is rather counter-intuitive. Continue reading