WatchFaceService has a method public void onPropertiesChanged(Bundle properties) which returns a bundle of properties. One of them has a key PROPERTY_OFFLOAD_SUPPORTED.
Here are all properties that are available in WatchFaceService:
public static final String PROPERTY_BURN_IN_PROTECTION = "burn_in_protection";
public static final String PROPERTY_LOW_BIT_AMBIENT = "low_bit_ambient";
public static final String PROPERTY_IN_RETAIL_MODE = "in_retail_mode";
public static final String PROPERTY_OFFLOAD_SUPPORTED = "offload_supported";
public static final String PROPERTY_PHYSICAL_HANDS = "physical_hands";
They are not there in the docs but can be accessed from Android Studio.
What does PROPERTY_OFFLOAD_SUPPORTED property represent, and how it should be used?
PROPERTY_OFFLOAD_SUPPORTED is related to WatchFaceDecomposition. This is a feature that's available on certain devices (built on the Qualcomm 3100 platform), where the ambient mode drawing of the watch face is handed over to a separate (very energy-efficient) piece of hardware.
There are a lot of restrictions for what you can and can't do in this mode. It also offers a few new opportunities such as more color options and having a second hand(!).
The feature is unfortunately not very well-documented but there are a few articles out there that talk about how to build watch faces that supports it:
http://turndapage.com/2018/12/07/implementing-the-new-ambient-second-hand-for-wear-os-with-watch-face-decompositions
https://www.programmersought.com/article/49454594831/
Related
We have requirements to let our users create their own workflows. Those workflows can have simple yes / no branching as well as waiting for a signal from an external event. This wouldn’t be such a problem if we had well established workflow definition, however since the workflows can be dynamic this poses a much tricker problem.
Temporal Workflows are code that directly implements your business logic.
For use cases when hardcoding the business logic in code is not an option an interpreter of an external workflow definition language should be written. Such language is frequently called DSL as they are really useful when implemented for a specific domain. The DSLs are frequently YAML/Json/XML based. Sometimes it is just data in DB tables.
Here is how I would structure the workflow code to support custom DSL:
An activity that receives current workflow definition ID and state and returns a list of operations to execute. This activity applies the current state (which includes results to the most recently executed operations) to the appropriate DSL instance. The result is the set of next operations to execute. Operations are DSL specific, but most common ones are execute activity, wait for specific signal, sleep for some time, complete or fail workflow.
A workflow that implements a loop that calls the above activity and executes requested operations until the workflow completion operation is requested.
Here is a sample code for a trivial DSL that specifies a sequence of activities to execute:
#ActivityInterface
public interface Interpreter {
String getNextStep(String workflowType, String lastActivity);
}
public class SequenceInterpreter implements Interpreter {
// dslWorkflowType->(activityType->nextActivity)
private final Map<String, Map<String, String>> definitions;
public SequenceInterpreter(Map<String, Map<String, String>> definitions) {
this.definitions = definitions;
}
#Override
public String getNextStep(String workflowType, String lastActivity) {
Map<String, String> stateTransitions = definitions.get(workflowType);
return stateTransitions.get(lastActivity);
}
}
#WorkflowInterface
public interface InterpreterWorkflow {
#WorkflowMethod
String execute(String type, String input);
#QueryMethod
String getCurrentActivity();
}
public class InterpreterWorkflowImpl implements InterpreterWorkflow {
private final Interpreter interpreter = Workflow.newActivityStub(Interpreter.class);
private final ActivityStub activities =
Workflow.newUntypedActivityStub(
new ActivityOptions.Builder().setScheduleToCloseTimeout(Duration.ofMinutes(10)).build());
private String currentActivity = "init";
private String lastActivityResult;
#Override
public String execute(String workflowType, String input) {
do {
currentActivity = interpreter.getNextStep(workflowType, currentActivity);
lastActivityResult = activities.execute(currentActivity, String.class, lastActivityResult);
} while (currentActivity != null);
return lastActivityResult;
}
#Override
public String getCurrentActivity() {
return currentActivity;
}
}
Obviously the real-life interpreter activity is going to receive a more complex state object as a parameter and return a structure that potentially contains a list of multiple command types.
ok, maybe I am missing something or worried to much...
I have a controller that generates my images. On a page it could have 100 or more images. For every image that is generated, the ImagingController is called.
I use dependency injection and notice that for every image that is displayed, the dependent classes are constructed.
src="#Url.Action("Thumbnail", "Imaging")/id"
private readonly IDBAccess _dbaccess;
private readonly ILogger _logger;
private readonly ISettings _settings;
private readonly IStateManager _statemanager;
public ImagingController(IDBAccess dbaccess, ILogger logger, ISettings settings, IStateManager statemanager)
{
this._dbaccess = dbaccess;
this._logger = logger;
this._settings = settings;
this._statemanager = statemanager;
}
public ActionResult Thumbnail(int id)
{
...
return File((byte[])data, "image/jpeg");
}
So every of the above 4 dependent classes are constructed 100 times. This seems a bit too much overhead or am I wrong?
It's possible to optimize this using lifetime management. If one or more of the dependencies are thread-safe, there's no reason to create a new instance for every request. Instead, you can reuse the same instance for all 100 requests.
This is called the Singleton lifetime style (not to be confused with the Singleton design pattern).
You don't write if you use a DI Container, or wire dependencies up by hand, so for details on how to do this, I'll refer you to my book, which both explains how to do it manually, and how to configure lifetimes for 6 different DI Containers.
In addition, you may also find this article useful: http://blog.ploeh.dk/2011/03/04/Composeobjectgraphswithconfidence
I just got some feedback about a job application Java coding exercise. They did not like the solution and two problems where stated in the feedback (which I'm very grateful for as it's very rare feedback is given):
I did not use TDD approach, apparently.
I overused static methods, I know static methods are anti OO but I only used them in validation and util type methods.
So two questions here:
What are the possible tell-tale signs of not using TDD approach?
What coding style or patterns can be an alternative to static methods?
Following the first two responses I have another question.
Do you agree that using static methods is only bad when it limits the testability of your code and not in them selves bad.
So going back to my job application exercise solution if the static methods do not limit the testability of my code is it still bad to use? my validate method was very simple 'Validator.notNull(p,"paramName")' now why would I ever want to mock that?
Many thanks.
A tell-tale sign of not using TDD is usage of static methods and static class members for collaborators. You cannot override a static method, so you cannot substitute a mock to test the class using such methods in isolation.
Instead of using static collaborators or static methods on the collaborators, you can use dependency injection. In a simple coding exercise you would inject dependency via a constructor or via the setters by hand. In the real life you can use one of available dependency frameworks.
Your static Validaton method seems something that should be part of an object to me.
Say you have an class Drink
public class Drink
{
private readonly string _name;
private readonly double _temperature;
public Drink(string name, double temperature)
{
_name = name;
_temperature = temperature;
}
}
Your businesslogic would be able to instantiate all kinds of drinks, 7up, cola, whatever. You'd like to make sure that a drink has the appropriate temperature to drink it, so you have the need for a Validate method. You could follow your approach:
public void TakeAZip()
{
if (Validation.HasAppropriateTemp)
{
// implement drink
}
}
'
Alternatives for static classes
That way you have an hard dependency on your static Validation class.
Alternatively you could make use of dependency injection.
public void TakeAZip(ITemperatureValidator validator)
{
if (validator.HasAppropriateTemp)
{
// implement drink
}
}
If more convenient you could also choose to pass the Validator via the constructor
private readonly string _name;
private readonly double _temperature;
private ITemperatureValidator _validator;
public Drink(
string name,
double temperature,
ITemperatureValidator validator)
{
_name = name;
_temperature = temperature;
_validator = validator;
}
Now you can mock the behavior of your validator and you can isolate your Drink class from all external behavior.
To create our test data, we use the following variation of the Builder pattern (simplified example!):
Sample class:
public class Person
{
public string Name { get; set; }
public string Country { get; set; }
}
The builder:
public class PersonBuilder
{
private string name;
private string country;
public PersonBuilder()
{
SetDefaultValues();
}
private void SetDefaultValues()
{
name = "TODO";
country = "TODO";
}
public Person Build()
{
return new Person
{
Name = name,
Country = country
};
}
public PersonBuilder WithName(string name)
{
this.name = name;
return this;
}
public PersonBuilder WithCountry(string country)
{
this.country = country;
return this;
}
}
NOTE: The context of the example itself is not relevant. The important thing here is how in the example, the a builder class like PersonBuilder can completely be generated by looking at the entity class (Person) and applying the same pattern - see below.
Now imagine that the person class has 15 properties instead of 2. It would take some monkeywork to implement the builder class, while theoretically, it could automatically be generated from the Person class. We could use code generation to quickly set up the builder class, and add custom code later if needed.
The code generation process would have to be aware of the context (name and properties of the person class), so simple text-based code generation or regex magic doesn't feel right here. A solution that is dynamic, not text-based and can be triggered quickly from inside visual studio is preferred.
I'm looking for the best way to perform code generation for scenarios like this.
Reflection? Codesmith? T4 templates? Resharper Live templates with macros?
I'm looking forward to see some great answers :)
The T4 solution is a well Visual Studio integrated option. You can use reflection inside the T4 template to actually generate the code.
We added a feature in CodeSmith Generator 5.x that allows you to generate off of existing code. Please take a look at that documentation here. Also you can use reflection or any .NET library in a CodeSmith Generator Template.
Thanks
-Blake Niemyjski
If it is for test only, consider a mocking framework like RhinoMocks:
internal class PersonBuilder
{
private MockRepository _mockRepository;
private IPerson _person;
public PersonBuilder()
{
_mockRepository = new MockRepository();
_person = _mockRepository.Stub<IPerson>();
}
public PersonBuilder WithName(string name)
{
_person.Name = name;
return this;
}
public PersonBuilder WithCountry(string Country)
{
_person.Country= Country;
return this;
}
public IPerson Build()
{
_mockRepository.ReplayAll();
return _person;
}
}
This way your builder can evolve along with your need. Further, you don't need to change your Build method. Just add "WithX" methods.
Have a look into the ABSE modeling approach and its IDE, AtomWeaver. ABSE is a template-based modeling and code generation framework, where a model (has nothing to do with UML or MDA) is created by applying "building blocks" (Atoms). These Atoms are template/program hybrids and are context-aware: an Atom can generate code according to its placement on the tree and on the presence/absence of certain Atoms.
The model host (AtomWeaver in this case) will "execute" the model in order to obtain the desired source code. The model can be "the source": change the model and regenerate as many times as necessary.
AtomWeaver is not integrated into Visual Studio, but can work alongside it without any problems.
Is it possible to design your own Java Type, similar to an extensible enum?
For instance, I have user roles that a certain module uses and then a sub-package provides additional roles.
What would be involved on the JDK side of things?
Since Enums can't be extended, you have to fake it.
Make a class with a protected constructor.
Then you can create public static final FakeEnum instances in your class.
public class FakeEnum {
private String name;
private Object something;
protected FakeEnum(String name, Object otherParam) {
this.name = name;
this.something = otherParam;
}
// public getters
public static final FakeEnum ONE = new FakeEnum("one", null);
public static final FakeEnum TWO = new FakeEnum("two", null);
public static final FakeEnum THRE = new FakeEnum("thre", null);
}
And then you can extend it and add some more things to it like so:
public class ExtendedFakeEnum extends FakeEnum {
public static final FakeEnum EXTENDED_ONE = new FakeEnum("extended_one", null);
public static final FakeEnum EXTENDED_TWO = new FakeEnum("extended_two", null);
}
Ok,
What I will do is write an interface and then several implementations for how to find users to notify in a particular event. The correct implementation will get injected at run-time and then it will do whatever it needs to do to find the correct users. That implementation may simply take arguments to configure the group name to look for and then return a list of users.
I am learning to use interfaces / design by contract more. Most of my development in the past has only ever had a single implementation so I saw this as a moot point and forgot about that tool / means.
Thanks,
Walter
The concept of an extensible enum doesn't make sense. An enum is used to declare statically the entire set of instances that will ever be made for its own type. Allowing it to be extended would make that impossible to ensure.
Designing your own type in Java is impossible. Anything you need to do can be done using various design patterns.
If you need an "extensible enum" it might be that a dictionary would suit you better, look at java.util.Dictionary<K,V> where K is the keyname (how you would refer to the particular value, and V is the value/object that should be returned by said Key.
I think thats the closest I've ever come to an extensible Enum.
Also, have a look at this question on SO, this might solve it too.