We want to do network performance monitoring by monitoring the api calls. Currently we are using Android Network monitoring which is integrated with Android Studio.
There are some problem with this framework. It can only give the amount of data transfer and receive. It doesn't give the number of api call. This metrics is really necessary to determine if there is unnecessary api call. Otherwise it would be hard to determine.
It is integrated with the Android Studio and we can't use it in the test framework because it just gives the graph which is also hard to compare the result.
I want to know if there is any framework available which can be used to get different metrics of Network performance.
Hey there is a library for this provided by Facebook. Please check:
network-connection-class [facebook-code-site] [github link]
A solution that can help you is Ixia's IxChariot.
IxChariot is a versatile product that is used for testing network peformance in various scenarios.
In your case, you can install the IxChariot endpoint on an Android device (download it from Google Play) and use the endpoint to generate traffic to and from the device and measure its network performance, in a lab environment.
Additionally, you have to install a second endpoint on the IxChariot server hosted in a cloud or public network.
Both endpoints must be configured to connect to the Registration Server located on the same machine as the IxChariot server. Once this configuration is complete, you can use the web interface to run various tests on the mobile data connection.
The range of available tests includes TCP, UDP, RTP, and VoIP traffic, with unlimited or configurable data rates. The reported statistics include Throughput, One-Way Delay, Jitter, Loss Rate, and MOS Score. IxChariot is capable of sending bidirectional test traffic, thus testing both the inbound and outbound directions of the mobile data connection.
Full disclosure - I work as Sr. Marketing Engineer at Ixia.
Related
I wrote an Angular app and its purpose is a mobile warehouse management system. The app is used primarily on mobile computers with an integrated barcode scanner. They are Honeywell TC60. This device has Android 8 OS and Chrome installed. The Honeywell device comes with a Barcode API that can be implemented in javascript. It does callbacks on port 8080.
I noticed the other day in the web console an error from Chrome:
[Deprecation] The website requested a subresource from a network that it could only access because of its users' privileged network position. These requests expose non-public devices and servers to the internet, increasing the risk of a cross-site request forgery (CSRF) attack, and/or information leakage. To mitigate these risks, Chrome deprecates requests to non-public subresources when initiated from non-secure contexts, and will start blocking them in Chrome 92 (July 2021). See https://chromestatus.com/feature/5436853517811712 for more details.
If I understand this correctly, in July the integrated barcode scanner API will be rendered useless and the company will have thousands of dollars in equipment that will no longer work with the integrated scanner API. Requests are made from the device which uses a public and secure domain to a private ip, however it is localhost. localhost you wouldn't think could have a vulnerability. since no outside call is actually being made.
I am not certain this targeted "feature" will break my scanner or not. Should I assume it will? There is no option on the device to require a secure local connection, if that even makes sense.
You should be able to verify the result by going to chrome://flags/ for a client machine and toggling the setting "Block insecure private network requests." from "default" to "Enabled".
In the case I observe, this error is shown when I make a request from an http internal website to an https internal website. The request fails to execute with said flag enabled.
My goal is to feed a NN on Android with real time streaming events from various data sources (sensors, other servers). I have created a working set up on a linux server with Kafka to explore the concept. Replicating this set up to an Android device poses the question if this is the correct architecture for a mobile device as well, or if I should go for a completely different approach.
Kafka on Android does not work (server especially, but client neither), and is not recommended due to required network connections.
More commonly, MQTT is used for streaming mobile and IOT sensor devices (which could in-turn send data to Kafka at the backend, collection site)
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I'm creating a viber-like application, i.e. android users can make instant messages in their android-powered devices. I've created client-to-server webservices using ASP.NET (ASMX service with JSON response) and it works like a charm, but the other side, i.e. server-to-client requests is just a little headache. Of course I can make my application so that there is no need to server-to-cliend requests (sending dummy requests from client to server in short periods) but in this way server will be overloaded specially when number of users increases. I've found some technologies regarding instant messaging, including GCM and XMPP. What are my other options? or let me ask what is my best option?
Should I use sockets? If so, how can I always have my clients IP (considering that clients are mobile users which may be using WiFi or GPRS/3G/4G internet). I'm thinking of a system in which my clients send their IP each n seconds (n can be around 30), so server always has a (nearly) up-to-date list of client IPs.
Is it possible or even logical to do so?
You should definitely consider using GCM (Google Cloud Messaging for Android)
You need to setup a few things in your server to be able to use it to send via GCM.
Its the built-in way to send data from a server to an android device, hope this can help
Implementing GCM Server
Using the good old strategy of long-polling is always possible, but there are much better ways to do it nowadays. That's perhaps the fastest to implement of the mentioned (not so if you want to implement it correctly and with min amount of load on your server/DB engine). I've seen some projects that start around that architecture with the idea to move to something better in the future .... and the moment to move never comes of course. If you start browsing your Android phone connected to a proxy like Charles you'll see what I mean :)
WebSockets are an option, but I don't see a reason why I'd use them for a Viber-like app, which is event-based (you've received a message) and not "real-time" (monitoring some stock graphics movements for example).
Your best choice here is a Google Cloud Messaging (GCM)! It's easy to implement it both on your backend and on the client, and it's built specifically with the problematic connectivity in mind (switching between wifi/poor 3g/4g/etc). It has some pretty nice features that other methods don't provide "out of the box" - message resending (the common scenario of a client loosing his connection - GCM it'll send the push notification later, when he comes online), automatic syncing between devices (smartphone, tablet, etc) and others.
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???