I am developing custom renderer for android and using LayerDrawable.SetLayerInsetRight method and works fine but that method is added in API level 23 and I am wondering what is equivalent to it in versions before 23?
Based on my research, you could use this method
SetLayerInset (Int32 index, Int32 l, Int32 t, Int32 r, Int32 b)
in versions before 23, this method was added in API level 1.
For example, if you set the layerDrawable.SetLayerInsetRight(1,30);in versions 23 or higher,you could set layerDrawable.SetLayerInset(1,0,0,30,0); in versions before 23
Related
So I recently was looking for a way to add extra metadata to logs and found out that syslog got me covered. I can add custom metadata using SD-ID feature like this:
[meta#1234 project="project-name" version="1.0.0-RC5" environment="staging" user="somebody#example.com"]
The problem is that 1234 has to be a syslog private enterprise number.
I assume those are given to big companies like microsoft or apple, but not to indie developers.
So My question is, is there a reserved number for internal use that everyone could use without registration for internal purpose?
If you use RFC5424-formatted messages, you can (or could) create custom fields in the SDATA (Structured Data) part of the message.
The latter part of a custom field in the SDATA is, as you mentioned, the private enterprise number (or enterpiseId).
As per RFC5424 defined:
7.2.2. enterpriseId
The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number that follows MUST be unique and MUST be registered with IANA as per RFC 2578 [RFC2578].
Of course it depends on what you're using it for, if it's only for local logs, you can use any enterpriseId or you can even use a predefined SDATA field with a reserved SD-ID and rewrite it's value. (See: syslog-ng Guide)
Using the older "Windows.Azure.ServiceBus" library, I am able to setup a SqlFilter that takes as its parameters a TimeSpan, but when I try the same using the "Microsoft.Azure.ServiceBus" library it fails with the following error:
Object is not of supported type: TimeSpan. Only following types are
supported through HTTP: string,int,long,bool,double,DateTime
What I am trying to do:
I want to have 2 subscriptions on my topic (highPriority, normalPriority)
Messages have a user property called "StartDate"
If StartDate <= 1 day, then it should go to highPriority subscription, else it should go to normalPriority. [i.e (StartDate - sys.EnqueuedDateTimeUtc) <= 24 hours].
Code that works (when using the older .net-framework Windows.Azure.ServiceBus package):
SqlFilter highMessagesFilter =
new SqlFilter("(StartDate-sys.EnqueuedTimeUtc) <= #TimeSpanImmediateWindow");
highMessagesFilter.Parameters.Add("#TimeSpanImmediateWindow", TimeSpan.FromDays(1));
var subscription = SubscriptionClient.CreateFromConnectionString(connectionString,topicName, subName1);
subscription.RemoveRule(RuleDescription.DefaultRuleName);
subscription.AddRule(new RuleDescription()
{
Name = RuleDescription.DefaultRuleName,
Filter = highMessagesFilter,
Action = new SqlRuleAction("set priorityCalc = (StartDate-sys.EnqueuedTimeUtc)")
});
Where as, this code (using: Microsoft.Azure.ServiceBus) doesnt work:
var filter = new SqlFilter("(StartDate-sys.EnqueuedTimeUtc) <= #TimeSpanHoursImmediateWindow");
filter.Parameters.Add("#TimeSpanHoursImmediateWindow",TimeSpan.FromDays(1));
var ruleDescription = new RuleDescription
{
Filter = filter,
Action = new SqlRuleAction(#"
SET HighPriority = TRUE;
SET Window = StartDate - sys.EnqueuedTimeUtc
"),
Name = RuleDescription.DefaultRuleName,
};
await managementClient.UpdateRuleAsync(topicPath,subscriptionName,ruleDescription);
The above code throws the following error:
Object is not of supported type: TimeSpan. Only following types are
supported through HTTP: string,int,long,bool,double,DateTime
If instead of managementClient.UpdateRuleAsync, I try using the following code:
var subClient = new SubscriptionClient(connectionString, topicPath, subscriptionName);
await subClient.RemoveRuleAsync(RuleDescription.DefaultRuleName);
await subClient.AddRuleAsync(ruleDescription);
It fails, with the following error (ServiceBusException):
Message The service was unable to process the request; please retry
the operation. For more information on exception types and proper
exception handling, please refer to
http://go.microsoft.com/fwlink/?LinkId=761101
The microsoft link is to a list of exceptions, and FilterException, but its not!
Here is the stack trace of the 2nd exception:
at
Microsoft.Azure.ServiceBus.Amqp.AmqpSubscriptionClient.OnAddRuleAsync(RuleDescription
description) in
C:\source\azure-service-bus-dotnet\src\Microsoft.Azure.ServiceBus\Amqp\AmqpSubscriptionClient.cs:line
132 at
Microsoft.Azure.ServiceBus.SubscriptionClient.AddRuleAsync(RuleDescription
description) in
C:\source\azure-service-bus-dotnet\src\Microsoft.Azure.ServiceBus\SubscriptionClient.cs:line
499 at UserQuery.Main() in
C:\Users\XXXX\AppData\Local\Temp\LINQPad6_quhgasgl\niqvie\LINQPadQuery.cs:line
82
So my questions are:
Can I use TimeSpan parameters using .net standard library? or will I have to use the older .net framework library if I wanted to use TimeSpans.
Is there a better way to implement what I am trying to do, a way that would work with the newer .net standard library? (FYI: I thought about sending the calculation as the parameter (decimal) and then the parameter would be a double, instead of a TimeSpan). And in fact, thats what I might end up doing.
If the library is throwing an exception stating that TimeSpan is not a supported type, then it's pretty much what you have. Note that the .NET Standard client has two implementations, the ManagementClient and some operations via entity clients, such as subscription client. The latter is implemented using AMQP. ManagementClient is entirely based on HTTP. While it would be ideal to use the AMQP implementation, it's incomplete. I would recommend relying on the ManagementClient. This is likely the reason why modifying rules using a subscription client is throwing an exception.
Regarding a better way - your idea sounds right. As long as it's not a type that the new client doesn't accept. Also, you can raise an issue with the library team at https://github.com/Azure/azure-sdk-for-net/issues if you'd like to know the reason why TimeSpan is no longer supported.
I try to port a Java web application to the new Java 8 Date&Time API (using 'LocalDate' and 'LocalDateTime' types among others)
In Java 7, java.util.Date could be used in JPA2 criteria API to filter result sets on dates. Typically one would do this by adding a predicate e.g.
..
predicatesList.add(builder.between(from.get(AccountLog_.valueDate), fromDate, toDate));
..
Now JPA2 doesn't support the new Java 8 Date&Time API (LocalDate and LocalDateTime) yet. With own "Attribute Converters", working with entities can already be achieved as described in the blog http://www.thoughts-on-java.org/persist-localdate-localdatetime-jpa/
Now to my question: how can I use LocalDate and LocalDateTime in JPA2 criteria API in order to filter the result sets on LocalDate instead of Date? 'between' as used previously doesn't work for LocalDate instances.
With my LocalDateTimeConverter, I just tried greaterThanOrEqualTo and lessThan to check for a LocalDateTime range like
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Meal> query = cb.createQuery(Meal.class);
Root<Meal> m = query.from(Meal.class);
query.select(m);
query.where(
cb.greaterThanOrEqualTo(m.<LocalDateTime> get(Meal.FIELD_WHEN), cb.literal(begin)),
cb.lessThan(m.<LocalDateTime> get(Meal.FIELD_WHEN), cb.literal(end))
);
return em.createQuery(query).getResultList();
and even
cb.between(m.<LocalDateTime> get(Meal.FIELD_WHEN), cb.literal(begin), cb.literal(end))
works as expected. What exactly is causing trouble with your code? Maybe <LocalDateTime> is missing?
I have a string which identifies a customer. On my website, I have 3 different images for customers who have not set a profile picture. I want to randomly associate one of these images to a customer, but not have the image change between sessions.
Is there any problems with using GetHashCode, like in the following code?
switch (CustomerIdString.GetHashCode() % 3)
{
case 0:
return "NoProfileImage0.png";
break;
case 1:
return "NoProfileImage1.png";
break;
case 2:
default:
return "NoProfileImage2.png";
break;
}
I understand there are other solutions, such as-
Use a better hashing library
Use the customer id as the seed in a random number generator
Persist the image name against the customer record
but I like the simplicity (no added libraries, no DB code) of using GetHashCode().
I found your example code useful in my application as I'm doing something similar. However, I found I needed to use Math.Abs around GetHashCode as it sometimes returns negative numbers:
Math.Abs(String.GetHashCode()) Mod 3
(Apologies that my reply is in vb.net rather than c#)
Related: Can I depend on the values of GetHashCode() to be consistent?
Basically,string.GetHashCode is not guaranteed to be the same across versions of the .NET framework.
You might want to consider using a hash function that exists in the broader scope outside of .NET (yet still is implemented in .NET!) and has an associated specification, for example MD5. That will make your software more portable and resilient.
For how to get a MD5 hash, see related: MD5 Hash From String
I don't see any issues with that, although it won't be random at all, it will always be the same image based on the value for CustomerIdString.
In trying to determing a if a specific connection is supported, I'm cofused about the difference between CoverageInfo.getCoverageStatus() and CoverageInfo.isCoverageSufficient(). For example:
// check mds with getCoverageStatus() and bitwise check
boolean hasMdsCoverage1 = (CoverageInfo.getCoverageStatus() & CoverageInfo.COVERAGE_MDS) == CoverageInfo.COVERAGE_MDS;
// check mds with isCoverageSufficient()
boolean hasMdsCoverage2 = CoverageInfo.isCoverageSufficient(CoverageInfo.COVERAGE_MDS);
Both hasMdsCoverage1 and hasMdsCoverage2 seem to return the same result, but why two different approaches? Is there ever a case where they'll return a different result?
Ideally I'd like to use CoverageInfo.isCoverageSufficent() since this looks cleaner in code, but before I do so I want to make sure I'm not missing out on anything that getCoverageStatus() would provide.
NOTE: I'm using this to check for valid connections via BIS, MDS, WAP and WAP2 protocols.
getCoverageStatus() returns A bitmask of COVERAGE_ flags*, where isCoverageSufficient() returns a boolean true if the device has the type of coverage specified by coverageType, over some available route; otherwise false. When coded the way you have there is no difference, but in hasMdsCoverage1 you have additional processing that makes them equivalent. isCoverageSufficient may be more convenient it this case, getCoverageStatus may be more convenient in others. I would not be surprised if the former calls the latter. There are many such examples in many different support libraries.